Posted by Jim Guerber (66.8.131.115) on November 09, 2004 at 08:54:17:
The QDIR file was used for years to keep information for Comet about files. In the olden days the DOS open File call was very slow so it was faster to keep file info in a file that stayed open for the whole time that Comet was running. The Windows file system has made great improvements in the performance of the open file call. Hardware has gotten much faster as well. For several comet releases (since Comet98), Comet has migrated file information from the QDIR file to the files themselves (when possible).
The QDIR record layout is such that long file names are not possible in Comet. This proposal will serve as an outline of how we plan to eliminate the QDIR file and thus implement Long File Names in Comet.
Keyed files, whether old or new extended keyed files, contain all information about the file itself in the .I00 file header.
Object files, whether Qantel objects, or old or new object format also contain all pertinent data within their object header. The only thing that must be modified in the object file header to implement long file names is the “source file name” field.
Sequential files and contiguous files may as well be the same file because their capabilities are identical as far as Comet is concerned. The only piece of information currently stored in the QDIR and nowhere else for this type of file is the record length.
The only other piece of information stored in the QDIR is the Comet Directory label.
If we eliminated the QDIR as the definitive source of file information for a Comet directory and instead, relied on the Windows file system, we could implement long file names within Comet.
Let’s make a utility that reads a Qdir file and does the following:
• Makes a file called cdir.dir that contains the 3 byte Comet Directory name.
• For each sequential file, makes a new file that contains only the record size. This file would have the same name as the sequential file itself with an extension of .CSF ???
• For each keyed and object file in the qdir, makes sure the appropriate info is in the files’ header.
On a diradd, the file system would find the cdir.dir file and know that this directory is of the new format.
File opens would utilize find first/find next to verify if a given file was in the directory or not. By extension, the file type would be determined.
.OBJ – object files – type determined by reading the file header
.I00 – Keyed file – Header determines whether extended keyed file or legacy keyed file
.CSF – Sequential file – record size found in the .CSF file
The question is what about the other file types? Are they all treated as text files? What about zip files, .PDF files, .HTML files etc. Should we be guided by the Windows Mime type info? (Can we get to this info?). Should some file types be “invisible”? Should they all be treated as text files?
Once converted, the new directory format would not be accessible by older Comet file systems (Novell). The conversion would be one-way and not reversible.
Only CFAM would be able to access the files in these directories.
The legacy utilities would not be able to deal with these files, especially since they may have long file names. Should we utilize the short file name or just eliminate the problem by specifically excluding legacy utility access for these new directories?
Character substitution in file names would no longer work.