Messages in this thread | | | Date | Tue, 5 Aug 2003 09:36:37 -0400 (EDT) | From | "Richard B. Johnson" <> | Subject | Re: FS: hardlinks on directories |
| |
On Tue, 5 Aug 2003, Stephan von Krawczynski wrote:
> On Tue, 05 Aug 2003 14:51:46 +0200 > Helge Hafting <helgehaf@aitel.hist.no> wrote: > > > Even more fun is when you have a directory loop like this: > > > > mkdir A > > cd A > > mkdir B > > cd B > > make hard link C back to A > > > > cd ../.. > > rmdir A > > > > You now removed A from your home directory, but the > > directory itself did not disappear because it had > > another hard link from C in B. > > How about a truly simple idea: > > rmdir A says "directory in use" and is rejected > > Which means you simply cannot remove the first directory entry before not all > other links to it are removed. This implies only two things: > 1) you have to know who was first. > 2) you have to be able to find out where the links are. > > Both sound solvable. > > Regards, > Stephan >
A hard-link is, by definition, indistinguishable from the original entry. In fact, with fast machines and the course granularity of file-system times, even the creation time may be exactly the same.
Without making one of the files different, and therefore not a hard-link, there is no way for an operating system to distinguish them except by keeping some list of hard-link inodes in some container file or some other such atrocious misconduct. Then every significant file operation would require a search of this inode-list to determine the special handling of such hard-linked directories.
A directory hard-link to the same directory will cause any recursive directory look-up to fail. It doesn't fail with sim-links because they are specifically different and can be excluded from the infinite recursion syndrome that would exist otherwise.
Somebody mentioned that VAX/VMS would allow hard-linked directories. This is not true. Even files, created with SET FILE ENTER=DUA0:[1.DIR] DUA0:[000000] that seemed like hard links were not hard links. They were sim-links. The file entry contained the directory information of the file being linked, and was not a clone of the header (inode) itself as would be a hard link. Therefore, these were unique and could not cause recursion to fail.
Cheers, Dick Johnson Penguin : Linux version 2.4.20 on an i686 machine (797.90 BogoMips). Note 96.31% of all statistics are fiction.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |