Re: Floppy disk strange behavior

[Mathieu Chouquet-Stringer <mchouque@e-steel.com>]

Ok, I emailed bug-fileutils@gnu.org and got this response from Jim Meyering
<jim@meyering.net>:

Thanks for the report.
That's fixed in the latest test release.
  ftp://alpha.gnu.org/gnu/fetish/fileutils-4.0.35.tar.gz

It's fixed in 4.0.33, too.

viro@math.psu.edu (Alexander Viro) writes:
> On Tue, 9 Jan 2001, Alan Cox wrote:
> 
> > > dd bug. It tries to ftruncate() the output file and gets all upset when
> > > kernel refuses to truncate a block device (surprise, surprise).
> > 
> > Standards compliant but unexpected. 
> 
> dd is supposed to be portable. On Solaris:
> % man ftruncate
> [snip]
>       EINVAL    The fildes argument  does  not  correspond  to  an
>                ordinary file.
>  
> > Actually its explicitly mentioned by the spec that truncate _may_ extend
> > a file but need not do so. 
> 
> However, it also explicitly mentions that truncate can fail for non-regular
> file.
> 
> > > Try to build GNU dd on other Unices and you will be able to trigger that
> > > bug on quite a few of them.
> > 
> > I think not
> 
> Solaris, for one thing. OK, let's ask folks to test it on different systems
> and see what it gives.
> 
> > > ftruncate(2) is _not_ supposed to succeed on anything other than regular
> > > files. I.e. dd(1) should not call it and expect success if file is not
> > > regular. Plain and simple...
> > 
> > 2.2 is least suprise 2.4 is most information, but misleading errno IMHO
> 
> Agreed. It should be -EINVAL, not -EPERM.
> 
> IMO there are two issues:
> 	* dd(1) portability bug. Obviously there - ftruncate(2) is allowed
> to fail on non-regular ones. Fix is trivial and it (or something equivalent)
> should go into the fileutils.
> 	* What should 2.4 do here? I would prefer -EINVAL - it is true
> (requested action is invalid for the arguments we got), it is consistent
> with other systems and it doesn't hide the failure. Data that used to
> be in the file we were trying to truncate is still there. -EPERM is
> arguably wrong here - it's not like the problem was in the lack of
> permissions.
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> Please read the FAQ at http://www.tux.org/lkml/
> 

-- 
Mathieu CHOUQUET-STRINGER              E-Mail : mchouque@e-steel.com
     Learning French is trivial: the word for horse is cheval, and
               everything else follows in the same way.
                        -- Alan J. Perlis
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/