From: Martin Str|mberg Message-Id: <199811021736.SAA17007@father.ludd.luth.se> Subject: Re: df adventures To: eliz AT is DOT elta DOT co DOT il (Eli Zaretskii) Date: Mon, 2 Nov 1998 18:36:08 +0100 (MET) Cc: djgpp-workers AT delorie DOT com (DJGPP-WORKERS) In-Reply-To: from Eli Zaretskii at "Nov 2, 98 09:51:11 am" X-Mailer: ELM [version 2.4ME+ PL15 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Reply-To: djgpp-workers AT delorie DOT com According to Eli Zaretskii: > I still would like to know what causes that "No such drive" error, and > whether "df r:" crashes or not after this patch (if it does crash, it > seems like a bug in `df', judging by the traceback). > > *** src/libc/compat/mntent/mntent.c~5 Mon Oct 12 23:22:50 1998 > --- src/libc/compat/mntent/mntent.c Mon Nov 2 09:27:10 1998 > *************** getmntent(FILE *filep) > *** 787,796 **** > /* Floppies and other disks written by Windows 9X include > entries that have volume label bit set, but they are > actually parts of some LFN entry. We only accept volume > ! labels which have all their RHS bits reset; otherwise > ! we pretend we never saw that label. */ > while (volume_found && > ! (mnt_ff.ff_attrib & (FA_RDONLY|FA_HIDDEN|FA_SYSTEM)) != 0) > { > volume_found = 0; > errno = ENMFILE; > --- 787,796 ---- > /* Floppies and other disks written by Windows 9X include > entries that have volume label bit set, but they are > actually parts of some LFN entry. We only accept volume > ! labels which have their HS bits reset; otherwise we > ! pretend we never saw that label. */ > while (volume_found && > ! (mnt_ff.ff_attrib & (FA_HIDDEN|FA_SYSTEM)) != 0) > { > volume_found = 0; > errno = ENMFILE; > This patch makes "df" work, i. e. R: is seen under condition that there is a CDROM with data in the drive. "df r:" works fine too in this case. However running "df r:" with no disk in the CDROM drive results in a crash: E:\>df3.exe r: Filesystem 1024-blocks Used Available Capacity Mounted on Exiting due to signal SIGSEGV Page fault at eip=00001ab2, error=0004 eax=00000000 ebx=0009a2f8 ecx=00000005 edx=00000001 esi=00000000 edi=000019d7 ebp=00099aa0 esp=00099a00 program=E:\DF3.EXE cs: sel=00a7 base=10000000 limit=0009ffff ds: sel=00af base=10000000 limit=0009ffff es: sel=00af base=10000000 limit=0009ffff fs: sel=008f base=000064d0 limit=0000ffff gs: sel=00bf base=00000000 limit=0010ffff ss: sel=00af base=10000000 limit=0009ffff App stack: [00099b40..00019b40] Exceptn stack: [00019a10..00017ad0] Call frame traceback EIPs: 0x00001ab2 _show_dev+78, line 273 of df.c 0x00001ff4 _show_point+168, line 512 of df.c 0x00002057 _show_entry+47, line 529 of df.c 0x00002cee _main+1554, line 779 of df.c 0x0000655e ___crt1_startup+174 The problem is this line in df.c: /* We couldn't find the mount entry corresponding to POINT. Go ahead and print as much info as we can; methods that require the device to be present will fail at a later point. */ { /* Find the actual mount point. */ char *mp = find_mount_point (point, statp); if (mp) { show_dev (0, mp, 0); ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ free (mp); } else error (0, errno, "%s", point); } In show_dev there's a strcmp using the third parameter: static void show_dev (const char *disk, const char *mount_point, const char *fstype) { ... /* JOINed disks seem like a directory on another disk. We want to see the info about the real drive. */ if (strcmp (fstype, "join") == 0) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ { struct stat real_drive_stats; So one solution would be changing the first line to "show_dev (0, mp, "");" Another one would be changing the second one to "if (fstype && strcmp (fstype, "join") == 0)". There's perhaps more of them. But I don't know what is the Right Way(tm) to do it. Perhaps Eli has the right answer? I'll ignore the "df: f:/: No such device (ENODEV)" trouble as this started when I have two primary FAT16 partitions on one (and only) hard drive. *DOZE was never intended to support this... Right, MartinS