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 11:55 Grant Edwards writes: > You might think so, but storing other things besides the unique > resource identifier in the filename makes it useless as a locking > mechanism. You're right, for applications where anything else is required. -- John Hasler jhasler(a)newsguy.com Dancing Horse Hill Elmwood, WI USA
From: Grant Edwards on 22 Feb 2010 12:11 On 2010-02-22, John Hasler <jhasler(a)newsguy.com> wrote: > Grant Edwards writes: >> You might think so, but storing other things besides the unique >> resource identifier in the filename makes it useless as a locking >> mechanism. > > You're right, for applications where anything else is required. Of course the traditional approach of creating a file whose name is the resource identifier and subsequently writing other info into that file works fine. It's semantically equivalent to the symlink approach, but it takes 3-4 lines of code compared to the 1 line for the symlink. -- Grant Edwards grante Yow! HUMAN REPLICAS are at inserted into VATS of visi.com NUTRITIONAL YEAST ...
From: John Hasler on 22 Feb 2010 13:41 Grant Edwards writes: > Of course the traditional approach of creating a file whose name is > the resource identifier and subsequently writing other info into that > file works fine. It is often not necessary to ever write anything into the file: it's mere existence provides all the information needed. In other cases I agree that the symlink is superior. -- John Hasler jhasler(a)newsguy.com Dancing Horse Hill Elmwood, WI USA
From: Robert Heller on 22 Feb 2010 15:24 At Mon, 22 Feb 2010 12:41:08 -0600 John Hasler <jhasler(a)newsguy.com> wrote: > > Grant Edwards writes: > > Of course the traditional approach of creating a file whose name is > > the resource identifier and subsequently writing other info into that > > file works fine. > > It is often not necessary to ever write anything into the file: it's > mere existence provides all the information needed. In other cases I > agree that the symlink is superior. Right! Firefox uses the symlink to record the host and pid of the locking firefox incarnation. In the event of firefox dieing unexpectly -- crashing, XKilled (eg logging out of X11 without cleanly exiting Firefox first), system crash, some joker using kill or killall on firefox, etc. (necessary in the event of runaway java and/or javascript [banning javascript would be a *good* thing -- DIE AJAX DIE -- need to design a T-Shirt someday]) -- a fresh firefox can check to see if firefox is really still running or if the lock file is orphaned. This is a 'friendly' thing. The alternititive is for firefox to become unusable everytime the lock file becomes orphaned (see above). By using a symlink it is possible to have a way to have an *atomic* way to create the lock file AND put the critical info in it. Otherwise there is the (slim, but non-0) chance of firefox dieing/killed between file creation and writing the critical info to it. -- 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: Darren Salt on 22 Feb 2010 15:17
I demand that Rahul may or may not have written... > unruh <unruh(a)wormhole.physics.ubc.ca> wrote in > news:slrnho147c.604.unruh(a)wormhole.physics.ubc.ca: >> I can change the uuid of a partition at any time I want. I can give the >> same uuid to anther partition. I can unmount the partition with that uuid. > Yes, if you want to mess up you always can. :) >> For inodes, they change when you reformat. But when you refomat you get a >> waring that all data will be lost. Do you really want all data on all >> disks to be lost if you replace one disk? > Why would data on "all" disks be lost? Only cross-FS links would dangle. And fsck would have to check both that FS and the link's target FS to determine whether the link is actually dangling. About the best that it can reasonably determine, AFAICS, is whether it's *not* dangling. Then there's the link count. Two of them would be needed; and what if a cross-device hard link were to disappear and the target inode's cross-device link count not be decremented? The only sensible way of implementing that that I can see is to reference the cross-device link from the target inode. However, there's still the possibility of there only being one link to the inode and that link being cross-device. This is where things *really* become silly; the file would, ideally, be moved automatically to eliminate the cross-device link... No, best to stay with the existing arrangement, even if it does mean that links have to be updated manually when a file is renamed or a mount point is moved. [snip] -- | Darren Salt | linux at youmustbejoking | nr. Ashington, | Doon | using Debian GNU/Linux | or ds ,demon,co,uk | Northumberland | Army | + http://www.youmustbejoking.demon.co.uk/ & http://tlasd.wordpress.com/ Your happiness is intertwined with your outlook on life. |