Hi all, I found back some old mails (8/2004) to Erwin about
EAthe findfirst/findnext has the wrong treatment for attribute selection
EAversus disk label
Some code lines from current unstable kernel (http://fdos.org/kernel/)
COUNT dos_findfirst(UCOUNT attr, BYTE * name)
...
if ((attr (D_VOLID|D_DIR))==D_VOLID)
...
/* Test the attribute and return first found*/
if ((fnp-f_dir.dir_attrib ~(D_RDONLY | D_ARCHIVE)) == D_VOLID
fnp-f_dir.dir_name[0] != DELETED)
...
COUNT dos_findnext(void)
...
if (fnp-f_dir.dir_name[0] != '\0' fnp-f_dir.dir_name[0] != DELETED
!(fnp-f_dir.dir_attrib D_VOLID)
...
COUNT DosFindNext(void)
...
/* findnext will always fail on a device name or volume id */
if (save_dta-dm_attr_fnd (D_DEVICE | D_VOLID))
I had a game which tried to find *.usr but the found list only contained
the volume label for FAT drives (does not happen for DOSEMU redir drives)...
My suggested patch was something like:
- if (dmp-dm_attr_fnd (D_DEVICE | D_VOLID))
-return DE_NFILES;
+ if ((dmp-dm_attr_find D_DEVICE) || (...))
+return DE_NFILES;
in dosfns.c DosFindNext (DosFindFirst is okay), or for testing:
+ if (dmp-dm_attr_fnd (D_DEVICE))
+return DE_NFILES;
(which would just remove the special D_VOLID treatment)
In addition, I had a patch suggestion for fatdir.c dos_findfirst:
- if ((attr (D_VOLID|D_DIR))==D_VOLID)
-i = 3;
+ if ((attr ~(D_RDONLY | D_ARCHIVE))==D_VOLID)
+i = 3;
...
- if ((attr (D_VOLID|D_DIR))==D_VOLID)
+ if ((attr ~(D_RDONLY | D_ARCHIVE))==D_VOLID)
The game called int 21.4e/4f with cx=dx=77a8, which has the D_VOLID
bit set, but which does NOT fulfill the requirements which would
trigger return (only) volume label according to RBIL. The cx/dx value
is there because the game did not care to set a proper value, but I
remember MS DOS had no problems with the funny value.
... ONLY return only the volume label if cx ffde equals 8.
I think if D_VOLID is set but attr ~(D_RDONLY | D_ARCHIVE) is not
EXACTLY D_VOLID, the redirect search to the root dir (i = 3; line)
should not happen. In addition, DosFindNext refuses to work if:
/* findnext will always fail on a device name device name or volume
id */ if (dmp-dm_attr_fnd (D_DEVICE | D_VOLID))
return DE_NFILES;
... where D_DEVICE is 0x40, as in DOS 3+ to indicate that a
findfirst-without- wildcards matched a device name (and therefore no
findnext hit can exist). This is again too picky: The search should
NOT end after the volume label unless the desired attributes
~(D_RDONLY | D_ARCHIVE) are exactly D_VOLID.
Eric
PS: Would be good to move the discussion to freedos-kernel.
(This already HAS been discussed on FreeDOS-kernel:
Date: Wed, 11 Aug 2004 01:17:52 +0200 (MEST)
Subject: [Freedos-kernel] 2035 findfirst bug: attr a8 treated as 08 if local
Reply by Bart:
Date: Thu, 12 Aug 2004 23:33:28 +1200 (NZST)
... before that, Arkady had some patches in 7/2004, and Bart did a partial
fix in 4/2003 to make MS CHKDSK work in FreeDOS ...)
---
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user
