Date: Tue, 15 Jul 1997 10:17:57 +1200 From: physmsa AT cantua DOT canterbury DOT ac DOT nz (Mr M S Aitchison) Subject: Re: Long FileNames To: caldera-opendos AT caldera DOT com Cc: opendos AT delorie DOT com Message-id: <199707142217.KAA03446@cantua.canterbury.ac.nz> Precedence: bulk I've had a deeper look into the long filename business, andI think I see what is going on. > From brannanp AT musc DOT edu Tue Jul 15 04:20:04 1997 > > > In a previous message, Mr M S Aitchison said: > > > 1. I had a zip file called HOME2.ZIP created on one system, copied > > > it to diskettem, took it to another PC, deleted it after use, and > > > created a new zip file called HOME.ZIP straight to diskette. That > > > now gives me a file with the short name of HOME.ZIP and the long > > > name of home2.zip. Strange, but probably not a bug in OpenDOS. > > > > You're probably right. It's probably a quirk of the implementation of > > VFAT. I assume the "other PC" used FAT? > > Why is an LFN being created for HOME2.ZIP anyway? Shouldn't that be a > short filename? I've just tried: longname/i pkzip -a c:\bak *.bak (creates BAK.ZIP; this pkzip -s a "legacy" app) copy c:\bak.zip d:\ dir d:\ (shows SFN: BAK.ZIP, LFN: bak.zip) longname/u del d:\bak.zip pkzip -a d:\bak2 c:\*.bak longname/i dir d:\ (shows SFN: BAK.ZIP, LFN: bak2.zip) The "other PC" I used before was running Win95, but at some stage in the proceedings I probably had it running in MSDOS7 mode (i.e. no LFN support). I strongly suspect the above behaviour, which was entirely under OpenDOS, would also have happened with Win95 (if I had the time to reboot all those times to enable/disable LFN support). It probably also happens lots of times without people realising when floppies are transferred between systems where only some have LFN support. The way long filenames are stored in FAT directories is hideous. For a start they take up many directory entries, which can be a problem in the root directory (which always has a limit on the number of entries). The method of obtaining the long names is inefficient and susceptible to things going wrong (mainly legacy apps, but that was the whole reason they choose this format, right?) What is going on in the example is that a legacy app creates a filename with capitals only in the directory entry, irrespective of the case supplied in the command line (as per normal DOS, even though there is LFN support). This is reasonable enough, since compatibility is important and it would be difficult for DOS to realise that the "bak" supplied in the command line corresponds with "BAK.ZIP" being created on disk, so it shouldn't unilaterally decide to change the case of the file being created. After that, I use the built-in copy command to put this file on a different disk... you might think that because the file is known on disk as BAK.ZIP the copy command would preserve the case when creating the copy on D:\, but it goes by the case of the file in the copy command line. It is reasonable that asking to copy "bak.zip" finds and copies "BAK.ZIP"; this is what most DOS users would expect, is compatible with Win95 and existing batch files, and is what what expect when we say that it "preserves case but is case-insensitive". The fact that it goes by the case in the copy command rather that existing filename is something that isn't such a hot idea, but I can live with that. As somebody else commented, the fact that it resorts to the LFN method (of creating extra hidden directory entries, with a special format that allocates two bytes per character of the original name) to store the short-but-not-all-capitals name is a design decision that seems strange when you think that they could have simply stacked those lower-case letters in a single (and otherwise normal) directory entry, but I can see how this is needed for compatibilty, so I can live with that as well. Now for the real problem: When this file is deleted on a non-LFN system, the deletion process doesn't touch those special hidden directory entries. If a new file is then created (reusing the same directory entry, in this case), the directory appears to a LFN system as having a long filename belonging to the new Short FileName, which is w-r-o-n-g ! There is a simple system built into the LFN design that allocates sequence letters at the start of each hidden special LFN hidden entry, and a checksum of the SFN. Possibly the OpenDOS implementation isn't checking the checksum correctly, but in any case there is a probability that sometimes the checksum will seem to be correct, simply because only 256 different checksums are possible. Of course, the LONGNAME support for OpenDOS is still in the early stages, and might have some minor bugs (the conversion of longname.pas to LONGNA~1.PAS is an example), but the major ones cannot be fixed without making the system incompatible with Win95 (at least as far as I can see). However, I expect this is still a good start, and applications can start using the DOS calls to access long filenames now, while people work on ext2fs support or hpfs or whatever, and let it use these new apps without the MS kludge and all its associated problems. ------------------------------------------------------------------------------- Mark Aitchison, Physics & Astronomy \_ Phone : +64 3 3642-947 a.h. 3371-225 University of Canterbury, (/' Callsign: ZL3TQE -------------------------------------------------------------------------------