Re: Floppy disk strange behavior

[Alexander Viro]

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.