1

FAT filesystems represent files via linked lists of clusters (linked file allocation).

They have a region on disk for one or more tables (File Allocation Table) which have as many entries as addressable clusters. Each entry can be:

  • a pointer to the next cluster in a file's linked list
  • a marker to indicate the last cluster of a linked list
  • an Unused marker
  • a Bad marker

For symbolic links, my guess is that the FAT can not point to or store a file path as ext filesystems do. The closest thing I can think of would be to point to the head of a linked list, which would require some sort of maintenance.

For hard links, FAT filesystems lack a file node that can be 'shared' among files. There would also be no way to keep track of the number of links to a file.

closed as off-topic by Rui F Ribeiro, Michael Homer, Romeo Ninov, GAD3R, Stephen Harris Jan 5 at 21:25

  • This question does not appear to be about Unix or Linux within the scope defined in the help center.
If this question can be reworded to fit the rules in the help center, please edit the question.

  • 5
    People, please don't use the "primarily opinion-based" close vote excuse for questions that ask for design rationale. The designers may have decided some things on a whim, or based on their opinion of how things should be, but even if so, what happened can be described as fact. It's not based on the opinions on whoever answers any longer. At most, this is off-topic, which is completely different. – ilkkachu Jan 5 at 18:44
  • Is this aimed the OP? I just want to know in what way this specific filesystem is limited to not support links. I can't see where opinion comes into play here. – juancho Jan 5 at 19:05
  • @juancho it's not aimed at you, but at the people who want to close your question. Notice that you can implement symlinks on msdos (for instance, hack the vfat linux module to store unix-specific metadata in a hidden file in each directory), but then that metadata will go out of sync when the fs is used on another system that doesn't know about that. Similar fate will befall a more low-level implementation. – Uncle Billy Jan 5 at 19:12
  • FAT is a legacy filesystem, and just does not implement links because it is the way the original was implemented. Pretty much the same reason why MS-DOS int 21h does not support all the Unix system calls. – Rui F Ribeiro Jan 5 at 19:16
  • 4
    I'm voting to close this question as off-topic because it is a systems programming question unrelated to Unix & Linux as defined in the help center – Michael Homer Jan 5 at 20:11
2

For the file system, I suppose the answer is "because it wasn't designed that way". That is, since none of the operating systems that used it as a main filesystem didn't want, need, or even came up with the idea of symbolic links, they weren't implemented.

As for the file system implementation/driver, support for symbolic links could in theory be added, but the file system needs a way to mark the file as a link, instead of a regular file (the link text can be stored like normal file data). Since the feature was never implemented, there's no pre-existing way to do that. One would need to pick some field of the directory entry to mark a file as a link, but then the implementation would not be compatible with other implementations. In the least, other systems would probably not bother to add support for the links, so they would not be supported.

Also, note that FAT is quite an old filesystem, and mostly only used in cases where interoperability is considered useful. With that in mind, changes to the existing standard are a bad idea, and for serious use, all operating systems have better filesystems that support links, amongst other things.

Hard links are even harder, since they pretty much rely on having the file name in a different place from the rest of the metadata. On Unix-type filesystems, the inode holds most of the metadata, and directories just contain pointers to the inode. On FAT, the directory entry contains the name and all other metadata, so there's no one place to keep the metadata of a file with more than one hard link to it.

  • So FAT fsystems lack the fields required to store file attributes such as pathnames (in the case of special file symlinks) and link counters (used by hard links). I guess that sums it up fairly in one sentence. – juancho Jan 5 at 19:02
  • @juancho, rather the fact that there's a file attribute bit to mark a directory, but none for a symlink, so no way know that a file is a symlink. You could make something up, but it wouldn't be compatible. For hard links it's worse since the filesystem structure is completely different. – ilkkachu Jan 5 at 20:09
  • 1
    it's not true that there's "support for symbolic links was never implemented" in the FAT filesystem -- there used to be umsdos. And the fact that it was using actual files to store the metadata instead of some low level hack doesn't detract from that -- after all, windows long names are also implemented as "hidden" directory entries in FAT. – Uncle Billy Jan 5 at 21:00
  • @UncleBilly, hmm yeah, I did forget about UMSDOS, but do note that I wrote about the systems that used FAT as their main filesystem, and I don't think Linux and UMSDOS counts for that, since it was always a bit of a compatibility hack. But really, you could write an answer about UMSDOS. I don't know too much about it to say anything. – ilkkachu Jan 5 at 21:04

Not the answer you're looking for? Browse other questions tagged or ask your own question.