[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)


        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

reply via email to

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