One of the rules for using data in a computer is that fully qualified names must be unique. That is, there can be at most one file with the name D:\d1\d2\d3\filename.xyz.abc and so on. If there were more than one, when you asked for a specific file the system would not know which to give you. That's true whether it's a Short File Name (SFN - maximum of eight legal characters, a period, and maximum of three legal characters) or a Long File Name (LFN - and with too many variations in legality to provide here). "Fully qualified" means including the full path from the drive letter through all the intevening directories/files to the file name. For these purposes, note that a directory or folder looks just like a file when viewed from the folder or directory at the next higher level.
In various places on your system, you probably have several files named read.me - or readme.txt or whatever. Suppose you wanted to put two read.me files into one directory. The OS would, quite properly, refuse. It can't put the second one there with the first because the fully qualified names would be identical. That would also be true with longfilename.txt - the fully qualified LFNs would be identical. The major problem arises when one has different fully qualified LFNs but one needs to have SFNs which are visible in and acccessible on a system using 8.3 names. MS decided to write the SFN logically, as 6~k.3 where k is a single character counting 1 to 9 to a to z (and on from there to 5~10.3, etc.). Now, there is an error in that process - which you will discover if you try to retrieve file longfi~c.txt, but that's not the point here. The point is that the fully qualified SFN must be unique in any system.
The SFN is not a property attached to the file. When a file is written to a directory (folder), an SFN is created. For an 8.3 name which is unique, the SFN matches the LFN. For a non-unique 8.3, you get the usual question: Do you want to overwrite? The same is true when you have unique and non-unique LFN's. The problem comes when you have a unique LFN but there is already a file in the directory/folder with the SFN that that LFN would generate.
In folder D1, you have longfilename4.txt with SFN longfi~7.txt - don't ask why, you just do. In folder D2, you have longfilename6.txt with SFN longfi~7.txt - perfectly feasible. Now you want to put those two files into otherwise empty folder D3. If the SFN's were preserved, the OS would have to refuse to put the second file into the folder - its fully qualified SFN would be the same as the first one's. However, you would have no way to repair the problem since you can't alter the SFN without renaming the LFN. So MS did the only logical thing: they did not preserve SFN's. When you write a file to a directory, if the LFN's are unique, a new SFN is generated in which the character after the tilde is invented. It's really the only way to do it.
If you have bothered to read this far, then play with the process to see how it works. One interesting variation is to write into an empty folder longfilename.txt - and then to try to write in longfi~1.txt which would have the same SFN (since the SFN of an 8.3 file is the 8.3 name). Also notice what happens when you write the LFN's in different sequences. It's all perfectly logical - but also very inconvenient for users who want to use SFN's in an LFN environment.
I would blame Microsoft for doing it wrong if I could figure out how to do it better.
E-mail me at cdrecording@mrichter.com
Return to Mike's home page