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: Robert Heller on 20 Feb 2010 22:44 At Sun, 21 Feb 2010 00:31:23 +0000 (UTC) Rahul <nospam(a)nospam.invalid> wrote: > > John Hasler <jhasler(a)newsguy.com> wrote in > ews:87r5ofqwf8.fsf(a)thumper.dhh.gt.org: > > likely that Apple and Microsoft would cooperate. Besides, we already > > have symlinks. > > > > > Subject: Re: hard links to files on other filesystems disallowed: why? > From: Robert Riches <spamtrap42(a)verizon.net> > > > If you were to attempt that and were able to find some way to > > refer to the other filesystem, what you're proposing would _BE_ a > > symbolic/soft link. > > Robert and John's response leads to this question: > > "Are there things that one can do with hardlinks which one cannot do with > symlinks? If I somehow enabled cross-filesystem hardlinks is that the same > as current soft-links? I think not." There are certain advantages a hard link has over a soft link, but they are somewhat limited -- I use them to create generic CGI scripts -- the scripts are all the same, using the REQUEST_URI to tell them apart. Because of the way Apache's suexec wrapper works the scripts need to have the proper owner/group and permissions (suexec does a security check and won't follow symlinks for security reasons). This is a rather specialized / special purpose case. In a more general there is little reason to prefer one over the other, except that symlinks are not symetric and hard links are. And this really only would make sense on a single file system anyway. Because of the way state is/is not preserved within / across file systems, almost any sort of 'cross file system' 'hard link' hack would not really be workable -- there are numberious ways things could/would break. -- Robert Heller -- 978-544-6933 Deepwoods Software -- Download the Model Railroad System http://www.deepsoft.com/ -- Binaries for Linux and MS-Windows heller(a)deepsoft.com -- http://www.deepsoft.com/ModelRailroadSystem/
From: Keith Keller on 20 Feb 2010 22:45 On 2010-02-21, Rahul <nospam(a)nospam.invalid> wrote: > > One big difference. Hardlinks are symmetric. THe data itself doesn't get > deleted till the last surviving hard link exists. > > With symlinks OTOH if the primary file is gone the link's broken. There is absolutely positively no way to reproduce the above hard link behaviour across filesystems. The result would have to be equivalent to either a symbolic link or a physical copy (the copy might be done just-in-time, but it would still have to be done at some point). Making a physical copy defeats the purpose of the link unless there's some mechanism for keeping the copies synchronized, which would certainly take additional software, which would very likely cause a lot of work for the disks. --keith -- kkeller-usenet(a)wombat.san-francisco.ca.us (try just my userid to email me) AOLSFAQ=http://www.therockgarden.ca/aolsfaq.txt see X- headers for PGP signature information
From: John Hasler on 20 Feb 2010 22:52 Rahul writes: > One big difference. Hardlinks are symmetric. THe data itself doesn't > get deleted till the last surviving hard link exists. I create one of your interfilesystem links from a directory on filesystem A to a file on filesystem B. Now I unmount filesystem A. Next I delete the file. What now? > With symlinks OTOH if the primary file is gone the link's broken. With your links if the filesystem containing the file is gone the link is broken. -- John Hasler jhasler(a)newsguy.com Dancing Horse Hill Elmwood, WI USA
From: Grant Edwards on 20 Feb 2010 23:35 On 2010-02-21, Rahul <nospam(a)nospam.invalid> wrote: > John Hasler <jhasler(a)newsguy.com> wrote in > ews:87r5ofqwf8.fsf(a)thumper.dhh.gt.org: >> likely that Apple and Microsoft would cooperate. Besides, we already >> have symlinks. >> > > > Subject: Re: hard links to files on other filesystems disallowed: why? > From: Robert Riches <spamtrap42(a)verizon.net> > >> If you were to attempt that and were able to find some way to >> refer to the other filesystem, what you're proposing would _BE_ a >> symbolic/soft link. > > Robert and John's response leads to this question: > > "Are there things that one can do with hardlinks which one cannot do with > symlinks? Definitely. Creating hard-links to directories can break a filesystem in ways that a symlink could never even approach. :) -- Grant
From: Grant Edwards on 20 Feb 2010 23:44
On 2010-02-21, Rahul <nospam(a)nospam.invalid> wrote: > John Hasler <jhasler(a)newsguy.com> wrote in > news:87r5ofqwf8.fsf(a)thumper.dhh.gt.org: > >> You could extend directory entries to include a filesystem identifier >> (such as a UUID) as well as an inode but you'd have to standardize that >> identifier over all the kinds of filesystems Linux can mount. Not > > It wouldn't have to be all encompassing. If I wanted a cross-FS hardlink > then I choose a uuid. The next time around if I remount and use the same > uuid then the link works else it breaks. > > Soft links break too once the dev is unmounted. The user can keep track of > the uuid assigned to devices that won't play fair (Apple, MAC etc.). For > some devices the uuid can be stored in the block dev. metadata. The reference counting mechanism that determines when an i-node is deallocated blows up into a massive problem if you try to do cross-filesystem links. I'm not sure if it's even a solvable problem. When you unmount a filesystem, do you decrement all of the reference counts on files linked to by the unmounted filesystem? Then increment them again when the referring filesystem is re-mounted? If not, how do you ever delete a file that is referred to by another unmounted filesystem? If you do allow such a file to be deleted, how do prevent a dangling link when that referring filesystem is re-mounted? Cross-filesystem links just doesn't seem practical for a Unix-like filesystem. -- Grant |