Specification of the Umsdos file system for LINUX

# Weakness and features

The UMSDOS file system is somewhat a compromise. Here are the drawback. -Space efficiency. The minimal allocation unit is generally 2k. Also, the MsDOS FAT fs do not support sparse file (file with gap of unallocated blocks). -General performance. UMSDOS run piggy back on top of another FS. This means two directory structure to maintain. -Maximum number of files is limited to 64k. It should be a good fs for many purpose, especially if you have to coexist with DOS. UMSDOS is trying to emulate the UNIX semantics for file system. Here are the known differences and weakness.

[linux/fs/umsdos/namei.c,503]
#Specification: weakness / hard link

The strategy for hard link introduces a side effect that may or may not be acceptable. Here is the sequence

    	mkdir subdir1
    	touch subdir1/file
    	mkdir subdir2
    	ln    subdir1/file subdir2/file
    	rm    subdir1/file
    	rmdir subdir1
    	rmdir: subdir1: Directory not empty

This happen because there is an invisible file (--link) in subdir1 which is referenced by subdir2/file.

Any idea ?

[linux/fs/umsdos/namei.c,522]
#Specification: weakness / hard link / rename directory

Another weakness of hard link come from the fact that it is based on hidden symbolic links. Here is an example.

    	mkdir /subdir1
    	touch /subdir1/file
    	mkdir /subdir2
    	ln    /subdir1/file subdir2/file
    	mv    /subdir1 subdir3
    	ls -l /subdir2/file

Since /subdir2/file is a hidden symbolic link to /subdir1/..hlinkNNN, accessing it will fail since /subdir1 does not exist anymore (has been renamed).

[linux/fs/umsdos/namei.c,980]
#Specification: weakness / rename

There is a case where UMSDOS rename has a different behavior than normal UNIX file system. Renaming an open file across directory boundary does not work. Renaming an open file within a directory does work however.

The problem (not sure) is in the linux VFS msdos driver. I believe this is not a bug but a design feature, because an inode number represent some sort of directory address in the MSDOS directory structure. So moving the file into another directory does not preserve the inode number.