Is there a file system that supports duplicate directory names.
Ideally to distinguish between directory names you would use indexes(file directory order).
This is related.
Is there a file system that supports duplicate directory names.
Ideally to distinguish between directory names you would use indexes(file directory order).
This is related.
No, there is no Unix system call to open a directory or file by inode, instead of by name. The concept of a directory entry's position in the list of directory entries doesn't exist, either.
If you think you want this, you probably took a wrong turn somewhere earlier in your design process.
If there were two directories called a
, then which one would a/file
refer to?
Directory entries are an unordered map from names to inodes, with names as the keys. Duplicate keys are not supported, and there's no way to create them. Any attempt to do anything with a name that already exists will just reference the existing directory entry.
Manually editing the on-disk data structures (or a kernel bug or hardware error) could produce a directory with the same name twice (maybe even pointing to different inodes), but this is a problem that fsck
would check for!
Say you run cat /home/peter/foo.txt
. cat doesn't read the directory at all, it just does open("/home/peter/foo.txt", O_RDONLY) = -1 ENOENT (No such file or directory)
. (strace cat foo.txt
to see.)
It might be possible to use FUSE to present a "filesystem" that interpreted special characters in filenames in some weird way, and returned directory entries in an order that had some meaning. If you're ok with placing limits on what characters can appear in a filename, you could give special meaning to some characters. So /mnt/database-fuse-mount/some_dir/{2}
might refer to the 2nd directory entry. Or .../name{2}
might refer to the 2nd entry called name
. I don't expect anyone has ever implemented this, unless maybe there's a FUSE module to mount database tables as directories with a file for each record. With the filename as the primary key? IDK, it doesn't really make sense, because an SQL database can be queried by any of its fields.
open(2)
system call. It takes a path, not an index into the directory. Otherwise there'd be a race condition between listing a directory and opening a file. If a new file was created by another process between your getdents(2)
and open(2)
, you'd get the wrong file.
Sep 3, 2015 at 20:53
/foo/bar/file
ambiguous. Which foo
does it refer to? There is no concept of a name's position in the list of directory entries. Directories entries happen to be returned in an order, which for most filesystems is the same every time, but it's really an unordered map. Adding a new name could re-order other names, depending on the FS. The abstraction layer you're looking for is called a "database", like Klaatu's answer says. What are you even trying to do with the filesystem that led you to consider this?
Sep 3, 2015 at 23:13
It's not a filesystem-on-disk, but any database would essentially do what you want to do. It's a layer of abstraction, and not visible as a set of directories and files in your file manager, but you could write a basic file manager for yourself if you really need one.
With a database, you could use key values to differentiate between "locations", the name fields could be duplicated as many times as you please, and you can access data by way of qeuries that look for matching combinations of fields in a table.
dir[0]
. If there is a directory there should be a directory indexdir[0]
instead of a directory locations.