3 ms·
(Note that everything in the sidebar is about "conventional Unix".) > A directory in a conventional Unix filesystem has either one name or no name (if it's bee
by deathanatos 3y ago
(Note that everything in the sidebar is about "conventional Unix".)
> A directory in a conventional Unix filesystem has either one name or no name (if it's been removed). Because of this, the kernel's name cache can always know the directory's current name if it has one. If it wants to, the name cache can go further and provide the last name that the directory was known by before it was deleted, along with a mark that it was deleted.
In Linux, you can end up with directories having different names via bind-mounting one path to another, or via two processes having different mount namespaces. IDK if you count inside/outside a chroot as "different" or not.
> A file can have no name (if it's been removed since it was opened or mmap()'d), it can have one name, or it can have several names because there are several hardlinks to it. Because of this the kernel name cache may not necessarily know the current name of an open file. If it started out having multiple hardlinks, was opened through one hardlink, and then that hardlink was removed, the name cache may not know the name of the other remaining hardlink(s).
It can also have no name if it was simply never given one; on Linux you can open a file without ever linking it, essentially. (See open(2), the O_TMPFILE flag.) Usually for the same semantics as the deleted tempfile (hence the name), just atomic.
I sort of wish it was in there from the beginning, as it is what I think the atomic rename to write a file pattern should really look like in the common case:
1. create the file via open(2) with no name.
2. write the contents
3. atomically link the file with rename's atomic replace semantics
That avoids the ugliness of the file needing some temporary name at all.
(Note that these files are disk-backed: the open call takes a directory which essentially becomes the backing FS for the data.)
There's also memfd_create(2), which is like the in-memory version of the above. You can't link those. (Yet…? if you had an in-memory FS … IDK, maybe it could make sense…? how much do you like plan9?)
- yjftsjthsd-h 3y agoI wonder what happens if you violate the 0 xor 1 rule by hard linking a directory - it is strongly discouraged for very good reasons but was at least historically possible ( https://askubuntu.com/questions/210741/why-are-hard-links-not-allowed-for-directories https://askubuntu.com/questions/210741/why-are-hard-links-no... comments discuss a bit in between the dire warnings). Or maybe it's not possible on newer systems that have such a cache?
- bombcar 3y agoApple allows hard linking directories (I believe it is used for Time Machine somehow): https://jameshunt.us/writings/linking-dirs-in-macos/ https://jameshunt.us/writings/linking-dirs-in-macos/
- stouset 3y agoIs that true on APFS? I know they added it to HFS+ for Time Machine, but I’d assumed it’s no longer necessary (or possible) with the newer filesystem that allows for real snapshots.
- comex 3y agoIt’s no longer possible.
- trws 3y agoI miss this in the days of APFS actually. As much as it’s potentially dangerous, in a system without bind mounts readily available it really was sometimes the best solution to a problem. Mainly used it to allow various directories that couldn’t be moved to be re-homed, looking at you OneDrive.
- Ericson2314 3y agoYou can do it with FUSE I'm pretty sure
- eru 3y agoYes. I've done that (but only on immutable filesystems, where it's not (much of?) a problem).
- yjftsjthsd-h 3y agoBeing ro helps with deleting directories (by preventing it, but w/e), but cyclical links would be bad regardless. Granted, it's the kind of thing that's probably okay if you know what you're doing well enough to avoid the footguns... but I have no experience, so can't say for sure.
- DeathArrow 3y agoLinux is not UNIX. It is a UNIX clone up to a point.
- deathanatos 3y ago… which is why I led the comment with, > (Note that everything in the sidebar is about "conventional Unix".) The OP isn't wrong (AFAIK), but most people are also not using OG Unix.
- dfox 3y agoWhile Linux is not derived from the original Unix codebase it is probably the nearest thing to UNIX in the sense of Single UNIX Specification that you can find.
- DeathArrow 3y agoWhat about macOS, BSD?
- dfox 3y agoThere are various (albeit notionally optional) parts of POSIX that are either not implemented at all or implemented in surprising ways on BSD derived systems. For example, macOS does not implement sem_init() at all, while OpenBSD sem_init(3) man page stilll says that "This is perhaps a stretch of the intention of POSIX, but is compliant, with the caveat that sem_init() always reports a permissions error when an attempt to create a shared semaphore is made." (that wording was at one time present in most BSDs, but both current NetBSD and FreeBSD seem to not have that limitation).