[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: proposed change to rcp
From: |
Alain Magloire |
Subject: |
Re: proposed change to rcp |
Date: |
Thu, 25 Oct 2001 21:38:54 -0400 (EDT) |
Bonjour
Interesting comments. Personnally I would that the ftruncate ()
should not be done if an error occured period. Unfortunately there is
no clear standard to follow for rcp. I would propose to follow the
same behaviour as "/bin/cp" for consistency and I do believe that for
GNU cp when an error occurs it just bail out (Is this correct Jim?)
> 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
>
>
> _______________________________________________
> Bug-inetutils mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/bug-inetutils
>