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.