proposed change to rcp

[Joseph Boyd]

Hello all,

We are seeing some unwanted behaviour with rcp/scp and wonder if anyone 
can see that our proposed change would cause any problems.

The root of the problem is that POSIX apparently doesn't define what the 
ftruncate call should do if the current file size is smaller than the 
"size" being given to ftruncate.  If the current file size is larger it 
just sets the size and the extra data is discarded.  From the man pages 
for (and tests on) Linux, Solaris, and Irix the ftruncate call just sets 
the size of the file to the size given to ftruncate.  If the file is 
currently smaller this creates a sparse file with a hole at the end. 
Since many of the major platforms have chosen to implement ftruncate 
that way I'm not sure I can fight that.

The problem is that since most popular filesystems support sparse files, 
even if the filesystem is full or a write error was received for some 
other transitory reason, the ftruncate in rcp still runs and sets the 
file size to "size".  Our somewhat non computer literate users see the 
write error at the end but then do an "ls -l" on their file and think it 
must have worked since the size is correct.  I'm not trying to defend 
our users I'm just stating that's what happens.

This can all be fixed though without causing any problems (I think) so I 
would like to propose the following change.

On line 800 of 1005 of the 1.3.2f tree there is a ftruncate call:

>if (ftruncate(ofd, size)) {
>     run_err("%s: truncate: %s", np, strerror(errno));
>     wrerr = DISPLAYED;
>}

ftruncate is called unconditionally after all of the file has been 
transferred and as much as possible written to disk.  What I would 
propose is that this code be wrapped inside an if statement with a call 
to fstat to see if the file size is currently smaller than "size" being 
passed to ftruncate.  If the file is currently smaller than "size" then 
the ftruncate should be skipped.

If you are copying over a file, the behaviour should be exactly the same 
as the current behaviour if you are copying over a larger file.

If you are copying over a file smaller then "size" the current behaviour 
can be worse than what I've proposed above as you might have some of the 
first part of the file new, a middle part of the old file, and then a 
hole.  With the behaviour from what I propose above you at least keep 
from having the hole at the end.  Either way it is foobar I would agree.

Even if you are doing "rcp /tmp/a localhost:/tmp/a" what I propose 
shouldn't cause a problem.

  I think putting the ftruncate call inside an fstat if/then would 
solve the problem of setting the size which causes a sparse file and not 
cause *any* other bad behaviour.

Does this make sense or does someone see a problem with this?

Thanks for your time,

joe