[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

proposed change to rcp

From: Joseph Boyd
Subject: proposed change to rcp
Date: Thu, 25 Oct 2001 15:12:50 -0500
User-agent: Mozilla/5.0 (X11; U; Linux 2.4.2-2 i686; en-US; rv:0.9.1) Gecko/20010622

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,


reply via email to

[Prev in Thread] Current Thread [Next in Thread]