hard links to files on other filesystems disallowed: why?
in [General Linux]
|
Prev: how does user application call NAPI poll method of network device driver.
Next: firefox and google maps
From: John Hasler on 22 Feb 2010 09:08 Robert Heller writes: > No. Creating an empty file is an atomic operation. There no need to write anything to it. > And merely touching the file stores no information. It stores the file name. Creating an empty file as a lock is commonplace. > Creating a symlink to 'nowhere' not only creates the link, it also > creates the path-like datum *at the same time*. That same data can be stored in the name of an empty ordinary file. The advantage of using a symlink is that it can (if short) be stored entirely in the directory, thus saving an inode. -- John Hasler jhasler(a)newsguy.com Dancing Horse Hill Elmwood, WI USA
From: Grant Edwards on 22 Feb 2010 10:20 On 2010-02-22, Rahul <nospam(a)nospam.invalid> wrote: > Jerry Peters <jerry(a)example.invalid> wrote in news:hls806$9mk$2 > @news.eternal-september.org: > >> But hard links can't dangle unless the FS is damaged. You'd now have >> to gracefully recover from a dangling hardlink. > > Why is it Ok for soft links to dangle but not hard links? Just > curious. Is it because a most legacy applications assume hard > links won't dangle? Or are there deeper reasons? In a Unix filesystem there's no such thing as a "dangling hard link" unless the filesystem has been corrupted. Dangling soft links are a "normal" condition. -- Grant Edwards grante Yow! HAIR TONICS, please!! at visi.com
From: Grant Edwards on 22 Feb 2010 10:22 On 2010-02-22, Rahul <nospam(a)nospam.invalid> wrote: > Florian Diesch <diesch(a)spamfence.net> wrote in news:712957-cmg.ln1 > @mid.florian-diesch.de: > >> That's often done because creating symlinks is an atomic action (in >> contrast to writing the data into a file). >> > > What about just "touching" a file. Isn't that an equally atomic operation? Yes. It's equally atomic. However, it contains less inforamation, since the only thing you can "store" using touch is the filename itself. With a soft link you "store" both the filename and the file contents. -- Grant Edwards grante Yow! I'll show you MY at telex number if you show me visi.com YOURS ...
From: John Hasler on 22 Feb 2010 11:26 Grant Edwards writes: > However, [a filename] contains less information, since the only thing > you can "store" using touch is the filename itself. With a soft link > you "store" both the filename and the file contents. 255 bytes is room enough for anything you'd need to put in a lock file. -- John Hasler jhasler(a)newsguy.com Dancing Horse Hill Elmwood, WI USA
From: Grant Edwards on 22 Feb 2010 11:42
On 2010-02-22, John Hasler <jhasler(a)newsguy.com> wrote: > Grant Edwards writes: > >> However, [a filename] contains less information, since the >> only thing you can "store" using touch is the filename itself. >> With a soft link you "store" both the filename and the file >> contents. > > 255 bytes is room enough for anything you'd need to put in a > lock file. You might think so, but storing other things besides the unique resource identifier in the filename makes it useless as a locking mechanism. For example, if you store both resource identifier and the owner identifier in the filename, then the whole concept of locking falls down: the two programs who are contending for the resource will attempt to create _different_ links. Both will succeed. You have to use globbing in your application to figure out if any "locks" exist for the resource ID in question, and then you've got a non-atomic locking sequence: 1) search/glob for lockfiles matching the resource 2) create lockfile for the resource OTOH, if you create a symlink, the name of the symlick is the resource identifier and the contents can contain owner ID, timestamp info, etc. All programs contending for the resource would attempt to create a symlink with the same _name_ but with different contents. That's an atomic operation and guarantees that only one program acquires the resource. -- Grant Edwards grante Yow! I have many CHARTS at and DIAGRAMS.. visi.com |