Ghosts of Unix past, part 4: High-maintenance designs

One thing I dislike about symbolic links, is if you move or rename the target, the link is broken. I have had the idea before of "smart links". Assign every file a unique ID, e.g. a UUID. Not inode number, since the inode number might be reused in the future for another file. Have an index on the filesystem of file ID -> inode. Provide an API to access this index, so we can open a file by unique ID rather than name.

A "smart link" then would store, not the name of its target, but the file ID. Even if the target is renamed, the link would still work. However, if the target is removed, the link no longer works, it is now broken.

Suppose, as well as assigning files unique IDs, we have a unique ID for each filesystem (again, a UUID would be good). Then I can smart link to a file on another filesystem -- the link contains fs ID and file ID. If the filesystem is mounted, and the file exists, the link will point to the file. Whereas, if the filesystem is not mounted, or it is but the file does not exist, the smart link is broken.

Within a single filesystem, one could implement referential integrity for smart links -- if the file is deleted, the smart links to it are deleted as well. This would require some form of reverse index, from file id of target, to the file ids of smart links to it. I guess we could support both types of smart links -- a flag on the link could indicate whether deletion of target should delete link or not. One could even implement referential integrity for cross-filesystem links, but I think that would be too complex to be worth it (e.g., how to deal with case where I know filesystem X contains a link, but I can't delete it because that FS is currently not mounted?)

If I was designing an OS from scratch, I would be inclined to give every file a single primary name, and then have smart links (rather than hard or symbolic links) to implement secondary names. But I also think, if we have filesystem APIs to access files by UUID, maybe we don't even names to be compulsory -- what is wrong with nameless files? Maybe filenames don't belong in the core FS, but in a higher layer (like some 'name DB' or 'catalogue'?) Maybe we should just have a three layer structure, Filesystem -> Directory -> File, with UUIDs to identify each. The "directory" is just to group related files for management purposes, e.g. quotas and access control. If one wants more layers of directories, that can be implemented in the "naming" upper layer, rather than in the "nameless" core filesystem...