[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,
joe
- proposed change to rcp,
Joseph Boyd <=