How do subdirectories work, and how many varieties exist?

[gsteemso]

There are apparently as many implementations of subdirectories as there are drive expansion projects -- LT Kernal, CMD native, VICE native, etc. If I want to fiddle a 1581 to access other sorts of disks than the Commodore-formatted ones, knowing what to present to a Commodore program so it won't choke on subdirectories is vital. Where can I find information on how to program with subdirectories on the most common implementations? Once I have that I can reverse-engineer something.

[hydrophilic]

I don't think there is any common format for subdirectories.  I would guess the 1581 was the most-used device supporting "directories" but since these were really partitions and didn't work in the usual manner (especialy when going up or creating one) few programs used them.

As I understand it, the usual method to change directories is to issue a command on channel 15 like "CD dirname".  The exact command varies between devices so I would suggest, for your program, to add the option to send drive commands... maybe a configure file/routine so the user can specify which command is needed by their hardware/emulator.

Also, I believe some "devices" like 64HDD alows a directory to be changed by LOADing it.  For example LOAD"dirname".  Personaly I don't own directory-capable devices, so the only real experience I have is with VICE using the file system.  It uses "CD dirname" to go down a level and "<-" (the left arrow, not cursor, key) to go up a level.

I'm not sure if you need this info, but a listing will identify directories differently.  For example, a 1581 will list a partion/directory as type "CBM".  The hardrives will usually list directories as type "DIR".  I think VICE use to show "DIR" but now it hides them completely!

Also, the 1581's "CBM" listing has a valid block size.  As I understand it, "DIR"s (if listed) show 0 for the block size, even if not empty.

That's my 2 cents.

[airship]

The 64HDD format is documented in the user guide. It's CMD compatible.

[BigDumbDinosaur]

Also, the 1581's "CBM" listing has a valid block size.  As I understand it, "DIR"s (if listed) show 0 for the block size, even if not empty.

In UNIX-like operating systems, directories have sizes, just like every other file, and the sizes are displayed in a "long listing" (i.e., ls -l).  A directory is nothing more than a file with a specialized internal structure.

[gsteemso]

Hmmm. Rats. What I want to do is load something into the 1581's internal RAM so it will respond to normal LOAD commands and so forth, but apply them to foreign (non-Commodore) disk formats, like HFS and FAT from the Mac and IBM worlds. As far as I can make out it shouldn't be too hard, but the subdirectory issue is tricky.

I suppose the obvious thing to do would be to treat the subdirectories like the 1581's native variety, but can the 1581 do -NESTED- subdirectories like a modern DOS? I will try to locate the 1581 user guide in Etext format, but as the things generally got less detailed over time, I'm not optimistic it will hold answers.

[hydrophilic]

The 1581 supports nested "directories" (partitions), BUT they can not be accessed with a full path.  For example you could have a structure like:
0 "DISK NAME" ID (root directory)
20 "FILE 1" PRG
160 "DIR 1" CBM
   20 "FILE 2" PRG
   80 "DIR 2" CBM
      20 "FILE 3" PRG

At the root level you can NOT access "FILE 3" or even "FILE 2" directly!  Only files in the root directory (only "FILE 1").  In other words, LOAD"FILE 1" is okay but LOAD"DIR 1/FILE 2" is not.  Simply, no paths!

You must descend into (open) "DIR 1" with a command-channel command of PRINT#15,"/0:DIR 1" -- only then can you LOAD"FILE 2".  Likewise, you must issue PRINT#15,"/0:DIR 2" before you can LOAD"FILE 3" and the PRINT# must be issued from within "DIR 1" because the "/0:DIR 2" will not work from the root directory.

Likewise, going up is also cumbersome.  From the lowest level (here, DIR 2 where FILE 3 exists) you can not directly go up to DIR 1 (to load FILE 2) because the only way to go up is with PRINT#15,"/0:" but it takes you to the root directory!  So from DIR 2 you'd have to issue two PRINT#s, one to return to the root and a second to go (back) down into DIR 1.

Inconvient?  Confusing?  Yes and yes which is why I wouldn't call the 1581 method the standard because few used it.

If you want to implement your own file system driver, you'll need to choose if you want to use the clumsy 1581 method or another.  VICE allows Unix style file specs like "//DIR 1/DIR 2/FILE 3".  On a Windows/DOS machine you can also use back-slashes instead of normal ones.  The "." and ".." directories also work.  I have plenty of experience with this and it works great.  This sounds like what you want but is different than that used by CMD Hardrives (and 64HDD says Airship).  Note: VICE only allows this method when accessing the host computer's file system.  If you are using 1581 disk images you must use the clumsy 1581 syntax.  (Unless maybe you "mount" the 1581 image into the host file system... I never tried it.)

The CMD format allows full file specs but the format is slightly different from Unix/DOS.  I believe the syntax is "0//DIR 1/DIR 2:FILE 3".  Three things to note.  First, the filename is seperated from the path by a colon instead of a slash.  Second, the "//" does not specify the root directory but simply seperates the partition number from the path.  I believe you must use three slashes "///" to reference the root.  Third, the 0 can be another number if you have multiple partitions in the hard drive.  Like the 1581, the 0 can be omitted in which case the last/current partition will be used.  This is my understanding from reading the CMD docs as I do not actually own one of their nice drives.

Hopefully this helps.  If not, I blame CBM DOS.

[brain]

Second, the "//" does not specify the root directory but simply seperates the partition number from the path.  I believe you must use three slashes "///" to reference the root.

The rest is correct, but this part is not.  // signifies an absolute path, while / signifies a relative path.

I implemented the CMD dirpath parser in the sd2iec/uIEC project, and have a CMD HD and FD here to verify operation, so feel free to email or PM for more information.

I would strongly (I'll see if I can find a more emphatic term later) recommend you implement the CMD-style commands.  They are (ironically) better supported than the 1581 sub-partitions, and they are easier to use.

For reference, note that sd2iec/uIEC currently supports CMD-style access to the FAT16/32 filesystem, and it works well.  I'm not sure of your plans, but there is also Big Blue Reader, etc. programs that offer FAT access to 720K DOS disks.

Jim

[gsteemso]

The only obvious questions I have revolve around what you might call "edge cases" -- the cases where the edges of the specification become evident. For example, how does the CMD DOS handle file or directory names that contain slashes and/or colons? You KNOW someone, somewhere, will use a sector editor to try it out just to see what happens. In a similar vein, what is the CMD syntax for going up a level or for referring to the current directory? Blindly expecting the UNIX-style "." or ".." to work is asking for trouble. Quite apart from that, what happens if a file or directory name has the same spelling as the specification for moving up a level?