3 ms·

Needs mention of auto-generated short file names (8.3 alias, typically with ~ in them) on volumes that don't support long names

Someone 4y ago
Not only there. Windows originally created them on disks that supported long names, too. That was necessary to support the use case where an older OS tried to read the disk (could happen because the user rebooted into an old DOS, for example, or if an external disk was moved to a different computer) https://en.wikipedia.org/wiki/8.3_filename#VFAT_and_computer-generated_8.3_filenames https://en.wikipedia.org/wiki/8.3_filename#VFAT_and_computer...: “VFAT, a variant of FAT with an extended directory format, was introduced in Windows 95 and Windows NT 3.5. It allowed mixed-case Unicode long filenames (LFNs) in addition to classic 8.3 names by using multiple 32-byte directory entry records for long filenames (in such a way that only one will be recognised by old 8.3 system software as a valid directory entry). To maintain backward-compatibility with legacy applications (on DOS and Windows 3.1), on FAT and VFAT filesystems an 8.3 filename is automatically generated for every LFN, through which the file can still be renamed, deleted or opened, although the generated name (e.g. OVI3KV~N) may show little similarity to the original. On NTFS filesystems the generation of 8.3 filenames can be turned off. The 8.3 filename can be obtained using the Kernel32.dll function GetShortPathName“
- zwieback 4y ago
  Right. Back in the 90s I worked on a network server to allow AppleTalk clients into DOS or OS/2 based networks. The Mac users enjoyed their filename freedom but the PC clients had trouble with the super-weird 8.3 short names. You couldn't really tell what the Mac filenames were. The other direction worked great, though, DOS filenames always worked on the Mac side of the network.

3 ms·

Needs mention of auto-generated short file names (8.3 alias, typically with ~ in them) on volumes that don't support long names

by zwieback 4y ago

Someone 4y ago
Not only there. Windows originally created them on disks that supported long names, too. That was necessary to support the use case where an older OS tried to read the disk (could happen because the user rebooted into an old DOS, for example, or if an external disk was moved to a different computer) https://en.wikipedia.org/wiki/8.3_filename#VFAT_and_computer-generated_8.3_filenames https://en.wikipedia.org/wiki/8.3_filename#VFAT_and_computer...: “VFAT, a variant of FAT with an extended directory format, was introduced in Windows 95 and Windows NT 3.5. It allowed mixed-case Unicode long filenames (LFNs) in addition to classic 8.3 names by using multiple 32-byte directory entry records for long filenames (in such a way that only one will be recognised by old 8.3 system software as a valid directory entry). To maintain backward-compatibility with legacy applications (on DOS and Windows 3.1), on FAT and VFAT filesystems an 8.3 filename is automatically generated for every LFN, through which the file can still be renamed, deleted or opened, although the generated name (e.g. OVI3KV~N) may show little similarity to the original. On NTFS filesystems the generation of 8.3 filenames can be turned off. The 8.3 filename can be obtained using the Kernel32.dll function GetShortPathName“
- zwieback 4y ago
  Right. Back in the 90s I worked on a network server to allow AppleTalk clients into DOS or OS/2 based networks. The Mac users enjoyed their filename freedom but the PC clients had trouble with the super-weird 8.3 short names. You couldn't really tell what the Mac filenames were. The other direction worked great, though, DOS filenames always worked on the Mac side of the network.