mkdosfs refuses to run on /dev/loop0p1

[Phillip Susi]

psusi@faldara:~$ sudo mkdosfs /dev/loop0p1
mkdosfs 3.0.9 (31 Jan 2010)
mkdosfs: Device partition expected, not making filesystem on entire device '/dev/loop0p1' (use -I to override)

Obviously this is wrong since loop0p1 IS a partition. Oddly, it does not complain on loop0p2.

[Jan Claeys (janc)]

This looks like the same bug we are seeing in GParted: https://bugzilla.gnome.org/show_bug.cgi?id=693955

This is caused by an incorrect test in mkdosfs whether a device is a "hard disk":

    if (fstat(dev, &statbuf) < 0)
        die("unable to stat %s");
    if (!S_ISBLK(statbuf.st_mode)) {
        statbuf.st_rdev = 0;
        check = 0;
    } else
        /*
         * Ignore any 'full' fixed disk devices, if -I is not given.
         * On a MO-disk one doesn't need partitions. The filesytem can go
         * directly to the whole disk. Under other OSes this is known as
         * the 'superfloppy' format. As I don't know how to find out if
         * this is a MO disk I introduce a -I (ignore) switch. -Joey
         */
        if (!ignore_full_disk && ((statbuf.st_rdev & 0xff3f) == 0x0300 || /* hda, hdb */
                                  (statbuf.st_rdev & 0xff0f) == 0x0800 || /* sd */
                                  (statbuf.st_rdev & 0xff3f) == 0x0d00 || /* xd */
                                  (statbuf.st_rdev & 0xff3f) == 0x1600) /* hdc, hdd */
        )
        die("Device partition expected, not making filesystem on entire device '%s' (use -I to override)");

It makes certain apparently incorrect assumptions about how raw device numbers for full disks vs. partitions look like.
(It also doesn't use major()/minor() on the raw device number, which looks not very portable or future-proof to me...)

[Phillip Susi (psusi)]

I guess I forgot to update this bug report. I found that a while back and sent off a patch to the upstream maintainer but have not heard back.

[Jan Claeys (janc)]

At least GParted will have the "-I" option workaround in the next version.

Did your patch remove the check or fix it? (Is there a future-proof way to fix it?)

[Phillip Susi (psusi)]

I didn't even think about the major/minor part, I just suggested adding another leading 0xf to the masks.

Personally I think the whole check for full disk is brain damaged and should be removed.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Jan Claeys (janc)]

https://bugzilla.redhat.com/show_bug.cgi?id=709266
Their fix: https://bugzilla.redhat.com/attachment.cgi?id=502487&action=diff

That was 2 years ago or so... :-/

[Jan Claeys (janc)]

I think the idea of such a safety check for interactive use isn't brain damaged, but in reality there is (or seems to be) no correct way to do this check, and even more so if you also consider other OS than linux, so I agree the only sensible thing to do is to remove it.

[Phillip Susi (psusi)]

Yea, that's pretty much what I came up with before the new year and I sent it off to the maintainer, but never got a reply.

I don't think this kind of safety check and prompt is unix like in character. It isn't the job of tools to second guess the admin and try to stop you from shooting yourself in the foot. This is why rm -rf / doesn't stop and warn you, even though doing this is monumentally stupid, and why none of the other mkfs tools try to do this.

Usually tools that try to do this sort of thing at least have the good sense to first check if stdin is connected to a tty, and skip the prompt if it isn't.

[Jan Claeys (janc)]

Actually, on modern unix systems "rm -rf /" will refuse to delete anything (unless you add a special option, like " --no-preserve-root" in GNU rm).

This follows POSIX.1-2008/SUSv4[1]:

| The rm utility shall remove the directory entry specified by each file argument.
|
| If [...] or if an operand resolves to the root directory, rm shall write a diagnostic
| message to standard error and do nothing more with such operands.

[1] http://pubs.opengroup.org/onlinepubs/9699919799/utilities/rm.html

[Phillip Susi (psusi)]

GAH! What is the world coming to?

[Jan Claeys (janc)]

Seems like there is a fix in dosfstools 3.0.15 now:

http://www.daniel-baumann.ch/gitweb/?p=software/dosfstools.git;a=blobdiff;f=src/mkdosfs.c;h=beda76f0fa87c85a6cd3bccb860865eaabc7143a;hp=25c520f972431310b038843a9d3bbd0eeba22fad;hb=b8201b34eb83c2bf87bd1c2b1a7fa57a1dc28191;hpb=7a756385ed6bce393396c699e068b5f239053db6

(Probably not the "right" solution, but I still wonder if it would be worth a backport of this patch?)

[Pali (pali)]

This issue should be already fixed.