H8DUtility 3 File Renaming Standardization

[Les Bird]

Hi all,

One of the features I'm adding to H8DUtility 3 is a file renaming standardization option. In trying to better organize and standardize the disk image names I've come up with this idea -  when the "RENAME ALL" button is clicked H8DUtility 3 will go through all the disk images and do the following:

1. It will attempt to read the HDOS label if it is a HDOS disk image.

2. It will then process the label by cleaning it up and eliminating any special ESC sequences.

3. It will replace all spaces with a dash.

4. It will replace all special characters with a dash.

5. It will read the contents of the disk image and create a checksum value by adding up all the bytes.

6. It will append the checksum to the end of the filename - this is a great way to identify identical disks that may be named differently.

7. If the disk label contains a part number, such as 885-1019, it will prepend the filename with the part number.

8. The part number and checksum value are separated by underscores, everything else is separated by dashes.

9. And finally it will make the filename ALL CAPS.

10. If the disk is not HDOS then it keeps the original name but cleans it up as described above and appends a checksum value to the end.

So here are some example screens. In one screen you can see the end result of the file renaming. In the part 'A' it has appended a checksum value to the filename and in part 'B' it has identified a part number and prepended the part number to the filename.

I'm curious what your thoughts are. This is done in-place so it is important to make backups of all files before processing them. My thought here is to do this for all the archives we have and replace the old ones with the new standardized ones. All future archives will use the new file naming format.

[Jeff Mowery]

I like the idea of naming consistency.

Virus-free. www.avast.com

--
You received this message because you are subscribed to the Google Groups "SEBHC" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sebhc+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/7c3a3c88-2aba-4709-a749-069471fef3fbn%40googlegroups.com.

[Glenn Roberts]

This seems well thought out.  tx.

 

But my mind goes back to the “jukebox” 😊.  I store all your images in a 512M reserved area of the Z67-IDE+ and reference (rapidly mount) them by slot number (attached).  I would love for us to move to a standardized volume/serial number for each image.  For compatibility with the Jukebox design we would need to use vol/ser numbers from 0 to 4095 for each class of disk (CP/M, HDOS).  That’s 8K of disks (well not quite – the larger disks take up multiple slots; each slot is 100K).

 

So perhaps think about if/how we could incorporate a vol/ser for each disk in the 0..4095 range.  If we had such a system it would be fantastic to have an ability (in the H8DUtility) to automatically rename a group of disks using their vol/ser (e.g. DISK0001.H8D, DISK0002.H8D…)  this would not be for human consumption but would allow us to automatically load the entire jukebox (or a portion thereof) based just on the vol/ser numbers (which would correspond to slots in the jukebox).  The software to load the jukebox uses VDIP commands which are limited to 8.3 DOS file naming conventions.

 

I know only a few of us are zealots about this now (Terry S and me? … but hoping to enlighten others once I write this up as a REMarks!) but the idea of a standard, unique image number for each disk would seem to have some merit.  Essentially the library “call number” for each disk!

 

• Glenn

[Les Bird]

Oh wow, this is very interesting Glenn. I could totally add this option to H8DUtility 3. If you tell me exactly how the naming should be, is it DISK0001.H8D, etc? What I can do is add a checkbox to the warning screen to name them in JUKEBOX format or something like that.

So DISK0000.H8D thru DISK4095.H8D? Did you build that spreadsheet by hand?

Les

[Glenn Roberts]

I think I created the jukebox index by simply downloading all the H8D files from the archive and doing (in a DOS command window):

 

DIR *.H8D >DIR.TXT

 

And then bringing that into Excel.  It’s trivial then to add the slot numbers.  As I recall I just did this for each of the volumes in the SEBHC archive (sequentially).  I have later added some on my own that may not be in the SEBHC archive. I built a program I call VTOC (view table of contents) which looks at each slot and prints the disk label information from sector 9 of the image (see attached) then added that to the spreadsheet.  There’s nothing magic about the order of the slot numbers – I just assigned them sequentially using the above process.

 

As far as exporting files for the purpose of creating the jukebox… Perhaps some thought about file naming convention is worthwhile.. possibly include the volume type?  E.g. HDOS0001.H8D… CPM20002.H8D… CPM30001.H8D   … in the (long shot) possibility that I ever get UCSD P system files working we could have UCSD0001.H8D … etc.  I have a program VLD (VDIP load – second attachment) that reads the files off the USB drive using the Vinculum software interface.  It can take many hours to read the H8D files and write them out to their jukebox slots (however you only do this once!).  The program as written requires an input file with the names of each H8D file (in 8.3 format as required by the Vinculum software) and their slot number, but if we had a file naming convention that included the slot number, things get more elegant,  e.g.

 

VLD HDOS

 

Could look for all files of the form HDOSxxxx.H8D (where xxxx is a vol/ser number == jukebox slot number) and load them in the appropriate slot.

 

Once we figure out how to do a jukebox for CP/M 2.2 you could similarly load those images with

 

VLD CPM2 (or whatever)….

 

Because the slots are 100K each, larger images must be given slot numbers that are divisible by 2, 4 or 8 (for 200K, 400K or 800K images).  The jukebox also doesn’t care if they were originally from H17 disks or H37 since HDOS images all follow the same basic format (not sure if this is true of CP/M…)

 

 

More food for thought: I think we will be limited in the amount of metadata that can be stored using just the files and file names, especially for CP/M.  HDOS is nice because we have the advantage of the HDOS volume number and label in sector 9.  It is worth thinking about the idea of a separate catalog/database that would contain all the appropriate information.  with that approach you could store vol/ser number, label, file name, and lots of other information (e.g. provenance information such as author, date, original source, company name, etc…)  There’s a pretty good case to be made for building a database (even just something in Excel or open office). 

 

If we made it a relational database (e.g. SQL) it could even contain all the names of the files within the disk images.  Something similar to what you’ve done with the HTML files (e.g. https://sebhc.github.io/sebhc/software/Applications/H8DCATALOG_VOL1.HTML) but more elegant and searchable.  Would make it trivial to find which volume(s) contain(s) a given file – that’s something we can’t easily do now (I basically load all your HTML files into an editor and do an ASCII search, or GREP if I’m on a UNIX box.  Pretty crude.)  Terry Smedley and I have also recognized the need for the Jukebox to have an index like this as well, and given some thought to that…  Here’s another thought: how do we catalog the appropriate documentation that goes along with each disk and make that searchable/findable in the database?

 

Seems like this is all worth some thought/discussion in the group…  IMO the preservation and cataloging of all the software (and accompanying documentation) is a core mission of this group and one that gets more difficult with each passing year as disks become harder to find or physically unreadable… Fortunately some of us still have significant troves of disks to catalog.  In addition to what you have (Les) I know Alex Bodnar has some that he’s working through, and Mark Garlanger has a significant collection.  I think I’ve probably still got some images that belong in the archive.

 

Preserving, cataloging, and sharing all of this is a noble cause!

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/347af93f-ccfe-4eae-a746-82d5c4c37712n%40googlegroups.com.