Timeline for Why are hard links to directories not allowed in UNIX/Linux?
Current License: CC BY-SA 3.0
10 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Aug 22, 2023 at 3:22 | comment | added | Jim Balter | There's no such thing as deleting a directory (or file) that has hard links to it ... they aren't deleted until the link count goes to 0. (Removing a name from a directory doesn't delete the named thing if there are links to it. Removing a directory name doesn't remove the ".." link to it.) It doesn't matter whether there is 1 parent or more, the issues are the same, The real reason is dealing with cycles ... they didn't want to maintain "visited" tables for dump and other programs that enumerated trees. But those tables now exist due to symlinks. | |
| Dec 26, 2017 at 4:31 | comment | added | ybungalobill | It's not what POSIX says, but IMO '..' should have never been a filesystem concept, rather resolved syntactically on the paths, so that a/.. would always mean .. This is how URLs work, btw. It's the browser that's resolving '..' before it even hits the server. And it works great. | |
| May 11, 2016 at 21:19 | comment | added | Lqueryvg | BTW, I'm not saying I'm in favour of hard links to dirs. Not at all. I don't want my day job to be harder than it is already. | |
| May 11, 2016 at 21:18 | comment | added | Lqueryvg | Sym links to dirs "violate settled semantics and behaviours", yet they are still allowed. Some commands therefore need options to control whether sym links are followed (e.g. -L in find and cp). When a program follows '..' there is further confusion, hence the difference in output from pwd and /bin/pwd after traversing a sym link. There are no "Unix answers"; just design decisions. This one revolves around what becomes of ".." as I stated in my answer. Unfortunately, '..' isn't even mentioned in the answer that everyone else is so sheepishly voting for. | |
| Feb 13, 2016 at 14:07 | history | edited | Lqueryvg | CC BY-SA 3.0 | added a little more clarity |
| Jan 29, 2015 at 12:04 | history | edited | Lqueryvg | CC BY-SA 3.0 | minor change |
| Jan 24, 2015 at 12:54 | comment | added | Lqueryvg | I agree. Not rocket science to solve. But nonetheless a performance overhead, and it would take up a little bit extra space in the file system meta data and add complication. And so the designers went for the simple, fast approach - don't allow links to hard directories. | |
| Jan 23, 2015 at 19:29 | comment | added | jathd | That's easy to solve as well: keep a list of parents of a child directory, which you update when you add or remove a link to the child. When you delete the canonical parent (the target of the child's ..), update .. to point to one of the other parents in the list. | |
| Nov 22, 2014 at 17:10 | history | edited | Lqueryvg | CC BY-SA 3.0 | trying to get Thorb's name right |
| Nov 21, 2014 at 12:54 | history | answered | Lqueryvg | CC BY-SA 3.0 |