Invalid Filenames

Overview

Exploring some of the filenames you can't use in Windows and all the Unix variants (Linux, Mac OS X, etc). Windows has arbitrary restrictions (Old legacy device files that don't actually exist), whereas the Unix ones deal with introducing invalid characters.

Windows

Recently Chris sent me a link to a paper describing Zombie OS Files in Windows. The short story is some seemingly straightforward names can not be used for a Windows file. The full list of names is: con, com, lpt, aux, prn, nul. This also includes some permutations like con1 and any extension like lpt.mp3

Experiment Setup

To test this I created a directory with 3 files called aux.txt, con.mp3, and goodFile.txt under Linux and placed it on a flash drive

• Could never unmount the drive
• Sometimes explorer would display the directory as empty
• Could not move, rename, copy, delete, open or modify the file. It gave either disk permission errors or file not found errors.
• Directory listings reported the proper file size, but the individual file properties displayed 0 bytes
• The same for other programs (I tried gvim) and DOS

DOS Session

Output of a DOS session:

Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

C:\Documents and Settings\gblack>E:

E:\>cd nameTest

E:\nameTest>dir
 Volume in drive E has no label.
 Volume Serial Number is 7851-F135

 Directory of E:\nameTest

07/16/2009  03:44 AM    <DIR>          .
07/16/2009  03:44 AM    <DIR>          ..
07/16/2009  03:21 AM                15 aux.txt
07/16/2009  03:21 AM         9,647,072 con.mp3
07/16/2009  03:45 AM           159,084 goodFile.txt
               3 File(s)      9,806,171 bytes
               2 Dir(s)   1,431,011,328 bytes free

E:\nameTest>dir aux.txt

 Directory of \\.

File Not Found

E:\nameTest>dir con.mp3

 Directory of \\.

File Not Found

E:\nameTest>dir goodFilename.txt
 Volume in drive E has no label.
 Volume Serial Number is 7851-F135

 Directory of E:\nameTest

07/16/2009  03:45 AM           159,084 goodFile.txt
               1 File(s)        159,084 bytes
               0 Dir(s)   1,431,011,328 bytes free

E:\nameTest>del aux.txt
The filename, directory name, or volume label syntax 
is incorrect.

E:\nameTest>del goodFile.txt

E:\nameTest>

Windows Conclusion

This is a silly bug, it was introduced to maintain backwards compatible with MS-DOS 2.0 over 20 years ago, and you'd think after the NT baseline was adopted it would be gone. At least there is always 0xDEADDEAD to reboot the thing :)

Unix

There are only a couple of illegal characters for filenames, namely \0 (null character) and / for directories. Which is fine, since you can't do this, unless you write directly to the block devices.

Experiment Setup

1. head -c 1000000 /dev/zero > data
2. losetup /dev/loop6 data
3. mke2fs /dev/loop6
4. mount /dev/loop6 someEmptyDir
5. #make some small files in someEmptyDir
6. umount someEmptyDir && losetup -d /dev/loop6
7. Open and edit how you want. For example in vim you can search for the filename and then in insert mode do CTRL+V 000 to insert a null character. The nedit program is even easier since nulls apear as so you can just copy and paste one easily.
8. Repeat steps 2 and 4, and then play around in the directory :p

Linux Results(ext2 fs, 2.6 kernel)

• Null in the middle of a file name. For example B�R
• ls reports errors both when inside and outside of a directory:
  ls: cannot access m/B: No such file or directory
• ls -l reports question marks for everything but name:
  -????????? ? ? ? ? ? B
• Can make and delete files normally
• fsck of the /dev/loop device it's on will fix the filename as B.R If B.R already exists it will move the existing one to B.~0 and then restore to B.R.
• Null at the beginning of a file name. For example �AR
• ls reports errors when inside a directory:
  ls: cannot access : No such file or directory
• ls does NOT report errors when outside a directory(IE ls directory)
• ls -l reports incredibly erroneous information for a blank filename(should be :
  drwxr-xr-x 3 root root 1024 Apr 3 05:58
  when it should look like:
  -rw-r--r-- 1 root root 9 Apr 3 05:58
• Can make and delete files normally
• fsck of the /dev/loop device will report size errors, and completely remove the filename �AR and it's associated inodes.
• Having / in a filename. For example B/R
• ls completely fails
  ls: reading directory .: Input/output error
• Can cd into the directory, but can't do anything. ls, rm, cat > file, all fail with I/O errors.
• fsck of the /dev/loop device will report size and naming errors. It will restore up to the slash. So for example if you had the files:
  first second th/rd fourth fifth
  It would recover first second and th, but erase fourth and fifth

Unix Conclusion

There are reasons you can't use / and \0 in filenames :) Doing preliminary testing in an OpenBSD VM completely crashed it, and I've spent too much time on this to explore it much more. Still interesting to see what fsck does and does not handle.