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: Jerry Peters on 21 Feb 2010 16:15 Rahul <nospam(a)nospam.invalid> wrote: > Jerry Peters <jerry(a)example.invalid> wrote in news:hlpmu1$331$5 > @news.eternal-september.org: > >> Let's suppose it also contained some sort of FS info. What would that >> be? It can't be a device number because there's no guarantee that the >> device number is a constant (USB devices in particular). So how do you >> "point" to the other FS? >> > > How about a uuid as the identifier? Then if I remounted the same system so > long as I use the same uuid the cross-filesystem hardlinks become > consistant again. > What do you do when the linked to FS is not mounted? With hardlinks the inode linked to *has* to exist unless the FS metadata is damaged. And how would you maintain the link count correctly if the FS is unmounted? Also do *all* FS have a UUID? Jerry
From: Jerry Peters on 21 Feb 2010 16:19 John Hasler <jhasler(a)newsguy.com> wrote: > Bill Unruh writes: >> I can change the uuid of a partition at any time I want. > > This would have to be a new, special filesystem UUID generated when the > filesystem was created and stored as part of the filesystem metadata. > You'd use a null UUID in directory entries for files on the same > filesystem as the directory so that the filesystem driver would bypass > all the UUID stuff when dealing with "local" files. > >> DO you really want all data on all disks to be lost if you replace one >> disk? > > Why would that happen? > >> If you made them hard as well, any change would loose you all your >> data. > > See above. Losing the filesystem UUID would merely cause all links into > the filesystem to dangle. But hard links can't dangle unless the FS is damaged. You'd now have to gracefully recover from a dangling hardlink. Jerry
From: Jerry Peters on 21 Feb 2010 16:26 despen(a)verizon.net wrote: > Rahul <nospam(a)nospam.invalid> writes: > >> Robert Riches <spamtrap42(a)verizon.net> wrote in >> news:slrnho11u4.i5f.spamtrap42(a)one.localnet: >> >>> If that were done, other than the difference between a symlink >>> being a path in text form and this new thing being a UUID and >>> inode number (at least partly in text form), what practical >>> differences would there be from a symlink? >> >> 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. > > Soft links are not broken when the file is gone. > > They are working exactly as designed. > > There is no requirement that the target of a soft link exist. > Try this command: > > cd /tmp > ln -s linktonowhere nowhere > > We have hard links for one purpose and soft links for another. And Firefox uses this feature for its lock: ~$ ls -l .mozilla/firefox/default.gox/lock lrwxrwxrwx 1 gap users 17 2010-02-21 16:00 ..mozilla/firefox/default.gox/lock -> 172.23.77.8:+2017 where 172.23.77.8:+2017 doesn't exist. Jerry
From: Florian Diesch on 21 Feb 2010 20:08 Jerry Peters <jerry(a)example.invalid> writes: > despen(a)verizon.net wrote: >> Rahul <nospam(a)nospam.invalid> writes: >> >>> Robert Riches <spamtrap42(a)verizon.net> wrote in >>> news:slrnho11u4.i5f.spamtrap42(a)one.localnet: >>> >>>> If that were done, other than the difference between a symlink >>>> being a path in text form and this new thing being a UUID and >>>> inode number (at least partly in text form), what practical >>>> differences would there be from a symlink? >>> >>> 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. >> >> Soft links are not broken when the file is gone. >> >> They are working exactly as designed. >> >> There is no requirement that the target of a soft link exist. >> Try this command: >> >> cd /tmp >> ln -s linktonowhere nowhere >> >> We have hard links for one purpose and soft links for another. > > And Firefox uses this feature for its lock: > ~$ ls -l .mozilla/firefox/default.gox/lock > lrwxrwxrwx 1 gap users 17 2010-02-21 16:00 > .mozilla/firefox/default.gox/lock -> 172.23.77.8:+2017 > > where 172.23.77.8:+2017 doesn't exist. That's often done because creating symlinks is an atomic action (in contrast to writing the data into a file). Florian -- <http://www.florian-diesch.de/misc/mitte.html>
From: Rahul on 21 Feb 2010 21:39
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? -- Rahul |