Path: utzoo!attcan!uunet!comp.vuw.ac.nz!massey.ac.nz!E.Ireland
From: E.Ireland@massey.ac.nz (Evan Ireland)
Newsgroups: comp.sys.ibm.pc.programmer
Subject: Setting Volume Label: summary, solution
Keywords: Volume, Label
Message-ID: <326sis-b@massey.ac.nz>
Date: 28 May 90 22:23:07 GMT
Reply-To: E.Ireland@massey.ac.nz
Organization: Information Sciences, Massey University, New Zealand
Lines: 93
Sender:

In my message of 24 April I asked how to go about setting the volume
label on a DOS formatted disk, and allowing it to contain `unusual'
characters.

Several people replied that I should use the FCB functions of DOS,
suggesting a number of books describing them, and one person sent
me C source code to use the FCB functions.  However, I found that
the FCB functions would not create `unusual' volume labels, in
effect doing nothing more than the DOS _CREAT interrupt (which is
not documented as being able to create volume labels, as far as I
can tell).

Thuan-Tit Ewe (tte@metaware.com) replied as follows (an answer I had
hoped I would not get!)

> What you want is a tall order. I however got around to doing this by
> first creating a file of known name; read the directory sectors searching
> for the file and then zapping the file name with whatever character I
> choose.

and also sent me a program that could do this.  However, since I
wanted to set volume labels from within my own application, I decided that
now was the time to learn about DOS disk structure!

Fortunately, last year I found an article "Disk File Organisation: A
Bit's Eye View" in Computer Language (March 1987 issue) and the other
day I pulled out my copy.  This article describes DOS partition, boot,
FAT, and directory tables in some detail, and with this information I
was able to write a working "set volume label" function for my
program.

For anyone else who wants to try this (I could send you some code),
what follows is the outline of my disk label function:

    Read the disk's boot sector (sector 0, if using DOS calls).

    From the boot sector, work out the number of root directory
    sectors (# root directory entries * size of directory entry (32) /
    bytes per sector) and the number of the first root directory
    sector (boot sectors + FAT sectors)

    For each directory sector:

        Read the directory sector.

	Search the sector for an unused (first byte of filename = 0)
	or erased (first byte of filename = 0x2e) directory entry, and
	if found set the filename to the required volume label (11
	characters max.), set the file attribute to LABEL (8), set
	date and time (volume creation time, displayed by CHKDSK),
	set file starting cluster and size to zero, and write the
	sector to disk.

	If not already found, continue searching for the previous
	volume label entry, and erase it (make first byte of filename
	= 0x2e).

Points to note
--------------

(a) It would appear that the only characters you cannot put in a volume
    label are 0 (meaning UNUSED entry) and 0x2e (meaning ERASED entry,
    can sometimes be unerased), and each of these cannot be used only
    for the first filename character.  Certainly graphic characters are
    permitted.  However you may get unusual effects if you put control
    characters in the label (I haven't tried this out yet).

(b) The Turbo C 1.5 absread and abswrite functions do not appear to
    restore register values correctly, so I had to compile with
    option -r- (register variables disabled).

Other questions
---------------

(a) Are there any IBM PC or compatible systems with other than 512
    byte disk sectors?  There is a field for sector size (in bytes) in
    the boot table but I imagine a lot of software assumes 512 byte
    sectors.

(b) The root directory may contain entries for subdirectories, and the
    starting cluster is given, but the file size field is always 0.
    Do all subdirectory tables only contain one cluster of sectors, or
    is it necessary to follow a chain of clusters in the FAT?  In
    other words, how do you determine the number of sectors/entries in
    a subdirectory?

(c) Has anybody else discovered the problem with TC 1.5 absread &
    abswrite, and a way to get around it without disabling register
    variables?  I could send a small (19 line) C program demonstrating
    this error to anybody who is interested.

				  Evan Ireland (E.Ireland@massey.ac.nz),
School of Information Sciences, Massey University, Palmerston North, NZ.