ade@pucc-i (D. Kakarigi) (08/16/85)
I am writing a program in which, among other things, I would like to
be able to read (and set or alter) disk's Volume-ID label. I was hoping that
I could use MS-DOS function call 4Eh to obtain the v-id label with attribute
byte set to 08 and the pathname set to *.*. To my surprise, 4E would return
the file name (and the rest) of the first file on the disk regardless of the
file attribute. In fact it seems that 4E function does not try to mach file
attribute as it is documented in the MS-DOS manual since most files have the
byte attribute of 20h and no matter to what value the CX register is set, 4E
only maches the pathname.
Am I not interpreting documentation correctly or is this a bug? BTW,
program is written in Turbo Pascal 3.0 and running on Pronto Series 16 with
MS-DOS 2.0. Also, I am aware of the alternate ways to do it (use absolute
disk read interrupt 25h to get the directory sectors and manipulate them
"manually").
DK {decvax|harpo|ihnp4|inuxc|seismo|ucbvax}!pur-ee!pucc-i!adejchapman@watcgl.UUCP (john chapman) (08/21/85)
> > I am writing a program in which, among other things, I would like to > be able to read (and set or alter) disk's Volume-ID label. I was hoping that > I could use MS-DOS function call 4Eh to obtain the v-id label with attribute > byte set to 08 and the pathname set to *.*. To my surprise, 4E would return > the file name (and the rest) of the first file on the disk regardless of the > file attribute. In fact it seems that 4E function does not try to mach file > attribute as it is documented in the MS-DOS manual since most files have the > byte attribute of 20h and no matter to what value the CX register is set, 4E > only maches the pathname. > > Am I not interpreting documentation correctly or is this a bug? BTW, > program is written in Turbo Pascal 3.0 and running on Pronto Series 16 with > MS-DOS 2.0. Also, I am aware of the alternate ways to do it (use absolute > disk read interrupt 25h to get the directory sectors and manipulate them > "manually"). > > DK {decvax|harpo|ihnp4|inuxc|seismo|ucbvax}!pur-ee!pucc-i!ade I think the problem is the wording of the manual. Mine says that the pattern you give is matched against any files with a more inclusive set of attributes. The 20h bit is the archive bit (set on when the file is created and whenever it is modified) and is useful for writing backup programs. If the attribute you give is 20h then it should match all files with that bit "on" regardless of the state of other bits but not files without that bit - conversely if you use an attribute byte with that bit "off" then you will also match against files with that bit on (as well as the ones with that bit "off"). You would also, for example, get files that are directories. If you set only the vol-id bit then you should get only the volume name but the path you give it should be * not *.* . Hope this helps. BTW - since you appear to be running turbo 3.0 under MS-DOS (as opposed to PC-DOS I assume) maybe you could answer a question of mine: does the generic version of 3.0 support tree structured directories (both as input pathnames to the compiler and in terms of being able to give an arbitrary pathname to open a file in a program)? The ads seem to imply that this available on the the PCDOS versions and not the generic MSDOS versions. thanks. -- John Chapman ...!watmath!watcgl!jchapman Disclaimer : These are not the opinions of anyone but me and they may not even be mine.
vch@rruxo.UUCP (Kerro Panille) (08/22/85)
> > I am writing a program in which, among other things, I would like to >be able to read (and set or alter) disk's Volume-ID label. I was hoping that >I could use MS-DOS function call 4Eh to obtain the v-id label with attribute >byte set to 08 and the pathname set to *.*. To my surprise, 4E would return >the file name (and the rest) of the first file on the disk regardless of the >file attribute. In fact it seems that 4E function does not try to mach file >attribute as it is documented in the MS-DOS manual since most files have the >byte attribute of 20h and no matter to what value the CX register is set, 4E >only maches the pathname. > Are you sure that you are looking at the root directory??? The volume label is in that directory only, and you have to search that directory in order to get it. Other than that, try to fudge it. Look for an entry with that attribute. BTW, the other attribute bits may be set on the volume label. Try setting the attribute to hidden, system, and volume label (0x0e). That may help. -- Vince Hatem +----------------------------------------+ Bell Communications Research !"..., isn't that right, Daniel?" ! Raritan River Software Systems Center ! "When you get that look on your face, ! 444 Hoes Lane ! Marty, I go prune my roses." ! 4D-360 ! -Frank Herbert ! Piscatway, NJ 08854 ! Chapterhouse: Dune ! (201) 699-4869 ! pg 459 ! ...ihnp4!rruxo!vch +----------------------------------------+
uh@unido.UUCP (08/25/85)
I always take this includefile for that task:
--------------- -Cut here -------------------------
(**************************************)
(* *)
(* INCLUDEFILE: GETVOL.INC *)
(* *)
(* VERSION : 1.03 *)
(* *)
(* RELEASED : 17-07-1985 *)
(* *)
(* AUTHOR : UWE HOCH *)
(* *)
(**************************************)
TYPE VOL_NAME_TYPE = STRING[11];
(**************************************)
PROCEDURE GET_VOL ( DISK : INTEGER;
VAR VOL_NAME : VOL_NAME_TYPE;
VAR ERROR : BOOLEAN);
VAR I : BYTE;
VOL_FCB : ARRAY [-7..36] OF CHAR;
VOL_DTA : ARRAY [0..127] OF CHAR;
REG : RECORD
AX,BX,CX,DX,BP,SI,DI,DS,ES,FLAGS : INTEGER;
END;
BEGIN
ERROR := FALSE;
REG.AX := $1A00;
REG.DS := SEG(VOL_DTA);
REG.DX := OFS(VOL_DTA);
MSDOS(REG);
VOL_FCB[-7] := #$FF;
VOL_FCB[-1] := #$08;
VOL_FCB[ 0] := CHR(SUCC(DISK));
VOL_NAME := '???????????';
MOVE(VOL_NAME[1],VOL_FCB[1],11);
REG.AX := $1100;
REG.DS := SEG(VOL_FCB);
REG.DX := OFS(VOL_FCB);
MSDOS(REG);
IF LO(REG.AX) = $FF THEN ERROR := TRUE
ELSE MOVE(VOL_DTA[8],VOL_NAME[1],11);
I := 11;
WHILE I > 0 DO
BEGIN
IF VOL_NAME[I] <> ' ' THEN
BEGIN
VOL_NAME[0] := CHR(I);
I := 0;
END
ELSE I := PRED(I);
END;
END;
----------------- Cut here -------------------
Uwe Hoch
Computer Science Department, University of Dortmund
4600 Dortmund 50, P.O. Box 500500, W.-Germany
E-mail address UUCP: ...ihnp4!hpfcla!hpbbn!unido!uhjohnson@noscvax.UUCP (Timothy A. Johnson) (08/27/85)
> > I am writing a program in which, among other things, I would like to > be able to read (and set or alter) disk's Volume-ID label. I was hoping that > I could use MS-DOS function call 4Eh to obtain the v-id label with attribute > byte set to 08 and the pathname set to *.*. To my surprise, 4E would return > the file name (and the rest) of the first file on the disk regardless of the > file attribute. In fact it seems that 4E function does not try to mach file > attribute as it is documented in the MS-DOS manual since most files have the > byte attribute of 20h and no matter to what value the CX register is set, 4E > only maches the pathname. > > Am I not interpreting documentation correctly or is this a bug? BTW, > program is written in Turbo Pascal 3.0 and running on Pronto Series 16 with > MS-DOS 2.0. Also, I am aware of the alternate ways to do it (use absolute > disk read interrupt 25h to get the directory sectors and manipulate them > "manually"). > I have come across this problem, also. I believe it is a bug in DOS versions prior to 3.0 (or at least 3.1). Calling function 4EH with *.* or ????????.??? and the attribute mask of 8 is correct. However, if the label happens to be the first non-deleted directory entry (in the root, of course), it will not be found. The function works as expected when at least one non-deleted file entry exists in the directory prior to the label entry. I found this to be true on both a Zenith Z-150 under MS-DOS 2.11 and an IBM PC under PC-DOS 2.1. When I tried the same program with an IBM PC and PC-DOS 3.1, it always found the label no matter where it was in the root directory. BTW: I suspect that using '*' as the file name mask is not sufficient since the label can have up to 11 characters and trailing three characters are stored in the same place as a normal file's extension. Tim Johnson Computer Sciences Corporation