Re: OLD kernel BUG with volume label? (MS works,2026..2027rc not)

On Wed, 6 Nov 2002, Arkady V.Belousov wrote:

> BO> int21 ah=4eh cx=21h ds:dx->"dodevlo"
> BO> int21 ah=4eh cx=21h ds:dx->"dodevlo*.*"
> BO> int21 ah=4eh cx=21h ds:dx->"dodevlo\*.*"
> BO> int21 ah=4eh cx=21h ds:dx->".dodevlo"
> BO> int21 ah=4eh cx=21h ds:dx->".dodevlo\*.*"
> BO> Might be 2,18,3,2,3
>
>      Nice choice: missing plain name - "no file found", missing name with
> wildcards - "no more files". :)

Right, this was following the DR-DOS docs here:
http://vger.timpanogas.net/drdos/sysprog/chap4.htm

" On return, if the Carry flag is set, AX contains error code 2 or 18.
Error code 2 indicates that the file was not found. Error code 18
indicates that no matching files could be found, when question mark
characters were used."

In any case, the documentation (attention Matthias!) is wrong here:
testing your debug script in DR-DOS 7.03 I got the same behaviour that you
found in MS-DOS. MS-DOS 7.10 also behaves in the same way.

>      Well, debug script:
[snip, thanks, I needed to make some small adjustments to get it to work
with FreeDOS debug]

>      ? Strange suggestion - 0 for missing name. MS-DOS returns same as above
> (18,18,3,3,3) in both case of existing _other_ vlabel and none vlabels.

I had the impression that for cx=8, the volume label was returned
regardless of the path given at ds:dx. So that's not true.

>      In all cases (any combination of asked attributes and attributes of
> other label) returned same results.

To conclude:
findfirst returns the following errors (besides critical errors):
3 if anything goes wrong before searching the directory (directory does
not exist, supplied name or pattern contains invalid DOS characters)
18 if the directory is searched but the pattern (regardless of question
marks) was not matched.

Volume labels:
if (cx & 8) then
  DOS tries to match the pattern against the volume label in the root of
  the drive. In this search the value of cx is ignored.

a volume label may also have r/o and archive bits set.

DR-DOS, unlike MS-DOS 7.1 treats root directory entries with the
volume label bit set and (system or hidden) bits set ALSO as volume
labels.

This means that if the drive has no volume label, but does contain LFN
entries in the root directory, then DRDOS displays a bogus volume label
and MSDOS correctly says "no volume label".

It is obvious that FreeDOS should mimic MSDOS and not DRDOS here.

The only question: why does RBIL state "2" as a possible return value,
where it seems to be impossible to get it?

Bart