Actually, there are two separate issues here, one is the name length, theYes, individual path name length elements limited to 36 characters is no great limitation - a 36 character filename in a directory with a name of 36 characters max should be pretty acceptable to most I'd have thought.
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.
We've down this road many times before, unless Marcel has new ideas to offer I don't really see the point of raising this again. Just because JRH managed to exceed 36 characters in his zip files!
In an indirect way, by defining the pseudo devices like DEV you can work around this to some extent in some circumstances if you are desperate. Setting the base devices for DOS to have longer Windows path names lets me access files in long and deep subdirectories in Windows from QPC2. When you are trying to cope with lengthy Windows network path names to shunt stuff from terminal to terminal at work (which I shouldn't be doing but occasionally need to when I use the office scanner on my colleague's machine and fetch the files using QPC2 on my office machine it's usually the only way because of the path name lengths. Fiddly, time consuming etc but possible if you get desperate.
All the suggestions Per made have merits I guess and if we don't debate them we'll never get them. I just don't get the impression that even Marcel The Miracle Maker will get this done soon!
-- Dilwyn Jones
-- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.300 / Virus Database: 265.6.9 - Release Date: 06/01/2005
_______________________________________________ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
