dd and kernel 2.4

[Mathieu Chouquet-Stringer]

          Hi!

I had this question on lkml and I thought it could be a good idea for you
to know the problem I discovered.
I have attached my mail and those from Alan Cox and Alexander Viro about
this problem.

     Thank for your efforts...

From: address@hidden (Mathieu Chouquet-Stringer)
Subject: Floppy disk strange behavior
Newsgroups: e-steel.mailing-lists.linux.linux-kernel
Date: 9 Jan 2001 15:36:57 -0500
Organization: e-STEEL Netops news server

        
        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 : address@hidden
     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 address@hidden
Please read the FAQ at http://www.tux.org/lkml/


From: address@hidden (Alexander Viro)
Subject: Re: Floppy disk strange behavior
Newsgroups: e-steel.mailing-lists.linux.linux-kernel
Date: 9 Jan 2001 16:24:03 -0500
Organization: e-STEEL Netops news server



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 address@hidden
Please read the FAQ at http://www.tux.org/lkml/


From: address@hidden (Alan Cox)
Subject: Re: Floppy disk strange behavior
Newsgroups: e-steel.mailing-lists.linux.linux-kernel
Date: 9 Jan 2001 16:38:08 -0500
Organization: e-STEEL Netops news server

> 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 address@hidden
Please read the FAQ at http://www.tux.org/lkml/


From: address@hidden (Alexander Viro)
Subject: Re: Floppy disk strange behavior
Newsgroups: e-steel.mailing-lists.linux.linux-kernel
Date: 9 Jan 2001 17:00:44 -0500
Organization: e-STEEL Netops news server



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 address@hidden
Please read the FAQ at http://www.tux.org/lkml/




-- 
Mathieu CHOUQUET-STRINGER              E-Mail : address@hidden
     Learning French is trivial: the word for horse is cheval, and
               everything else follows in the same way.
                        -- Alan J. Perlis