Floppy disk strange behavior

Floppy disk strange behavior

[Mathieu Chouquet-Stringer]

	
	Hi!

I have switched a long time ago to linux-2.4 (and even 2.3 series) and I
have a wierd problem.
I use GRUB to boot my system. Basically, when you want to install GRUB on a
floppy disk, you do that:

dd if=stage1 of=/dev/fd0 bs=512 count=1
dd if=stage2 of=/dev/fd0 bs=512 seek=1

But since kernel 2.3.xx (I don't remember exactly), I got this error
message when I try to do the second dd (even as root):
dd: advancing past 1 blocks in output file `/dev/fd0': Permission denied

And this thing works properly when under 2.2.xx...

I try to look a the diff of floppy.c between 2.2.18 and 2.4.0 but at this
time, I didn't find anything...
-- 
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/

Re: Floppy disk strange behavior

[Alexander Viro]

On 9 Jan 2001, Mathieu Chouquet-Stringer wrote:

> I use GRUB to boot my system. Basically, when you want to install GRUB on a
> floppy disk, you do that:
> 
> dd if=stage1 of=/dev/fd0 bs=512 count=1
> dd if=stage2 of=/dev/fd0 bs=512 seek=1
> 
> But since kernel 2.3.xx (I don't remember exactly), I got this error
> message when I try to do the second dd (even as root):
> dd: advancing past 1 blocks in output file `/dev/fd0': Permission denied

dd bug. It tries to ftruncate() the output file and gets all upset when
kernel refuses to truncate a block device (surprise, surprise).

Workaround: use conv=notrunc.

Proper fix:
ed src/dd.c <<EOF
/^main/
/^$/i
	struct stat stat_buf;
.
/HAVE_FTRUNCATE/i
	if (fstat(STDOUT_FILENO, &stat_buf) < 0)
	        error (1, errno, "%s", output_file);
	if (!S_ISREG(stat_buf.st_mode))
		conversions_mask |= C_NOTRUNC;
.
w
q
EOF

Notice that for regular files dd will truncate everything past its
output unless you say notrunc. This behaviour obviously makes no
sense for devices - they have fixed size and there's no way in hell
to truncate a floppy (well, there is, but it requires manual
operations ;-) The _only_ possible behaviour for anything except
regular files is notrunc one. Patch above forces notrunc for everything
that is not a regular file.

Basically, dd(1) expects kernel to fake success for ftruncate() on the
things that can't be truncated. Bad idea. 2.2 didn't bother to report
error in that case, so this bug didn't show up. 2.4 (and many other
Unices) return error and dd fails when you have block device as output file,
non-zero as initial seek and don't have notrunc.

Try to build GNU dd on other Unices and you will be able to trigger that
bug on quite a few of them.

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...

-
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/

Re: Floppy disk strange behavior

[Alan Cox]

> 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. 

> Basically, dd(1) expects kernel to fake success for ftruncate() on the
> things that can't be truncated. Bad idea. 2.2 didn't bother to report

Actually its explicitly mentioned by the spec that truncate _may_ extend
a file but need not do so. 

> 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

> 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

-
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/

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.

-
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/

Re: Floppy disk strange behavior

[Mathieu Chouquet-Stringer]

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/

Re: Floppy disk strange behavior

[Alan Cox]

> 	* 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.

I'd prefer EINVAL. I agree on the rest

-
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/

Re: Floppy disk strange behavior

[Andries.Brouwer]

>> dd: advancing past 1 blocks in output file `/dev/fd0': Permission denied

> dd bug. It tries to ftruncate() the output file and gets all upset when
> kernel refuses to truncate a block device (surprise, surprise).

Yes. But EPERM means that something is wrong with privileges.
One would expect EINVAL or so when something is wrong with the
way the routine was called.

Let me find my docs :-)

===== austin - d5 ============================================
...
If fildes refers to a regular file, the ftruncate( ) function shall cause
the size of the file to be truncated to length. If the size of the file
previously exceeded length, the extra data shall no longer be available
to reads on the file. If the file previously was smaller than this size,
ftruncate( ) shall either increase the size of the file or fail.
XSI-conformant systems shall increase the size of the file.
If the file size is increased, the extended area shall appear as if it
were zero-filled. The value of the seek pointer shall not be modified
by a call to ftruncate( ).
...
If fildes refers to a directory, ftruncate( ) shall fail.
...
If fildes refers to any other file type, except a shared memory object,
the result is unspecified.
=============================================================

No info on errors here.

===== Digital Unix man ======================================
...
The path parameter must point to a pathname which names
a regular file for which the calling process has write permission.
...
[EINVAL] The file is not a regular file
=============================================================

So, as was to be expected, other systems use EINVAL in this
situation, and so should we.

Andries
-
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/