Mail Archives: djgpp-workers/1998/11/02/12:36:53
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
- Raw text -