Floppy disk strange behavior

	
	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 : [email protected]
     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 [email protected]
Please read the FAQ at http://www.tux.org/lkml/

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 [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Standards compliant but unexpected.

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

I think not

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 [email protected]
Please read the FAQ at http://www.tux.org/lkml/

dd is supposed to be portable. On Solaris:
% man ftruncate
[snip]
EINVAL The fildes argument does not correspond to an
ordinary file.

However, it also explicitly mentions that truncate can fail for non-regular file.

Solaris, for one thing. OK, let's ask folks to test it on different systems and see what it gives.

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 [email protected]
Please read the FAQ at http://www.tux.org/lkml/

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 [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Ok, I emailed [email protected] and got this response from Jim Meyering <[email protected]>:

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.

Mathieu CHOUQUET-STRINGER              E-Mail : [email protected]
     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 [email protected]
Please read the FAQ at http://www.tux.org/lkml/