Perhaps we should have another bash at finding a solution to our debilitating filename length problem?
Actually, there are two separate issues here, one is the name length, the other is the path depth. Personally, Im not too fussed about file or directory names being limited to 36 chars, although ideally it should be more like 255+ chars for compatibility with various advanced barbarian systems. However, were not likely to see a shiny new file system anytime soon, so perhaps we should be looking for a solution that merely increases path depths with a minimum negative impact. One solution might be to replace filenames in the file header and directory files with an index into a filename database (many variations on this solution) Another, which already exists but has not received much support, is to use the non-directory device driver facility to emulate a directory device driver [DDD], similar to what Marcel has done with www addresses in TCP. A third possibility, would be to change the (or create a new, parallel) DDD so that it only stores the name of the /next/ directory in the space reserved for the name. This would allow unlimited path depth, but each link in the path - and the file name itself - could only be 36 chars long. If possible, both systems should operate side by side. All suggestions above would require changes to programs that read the directory structure and to any programs that expect the total name length to be 36 char. To ease the situation in the event of future upgrades or changes to the file system, manipulating the directory should only be done via system calls, ie there should be no need for programs to fool around in the raw directory structure as is the case at present. Let battle commence! Per _______________________________________________ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
