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 Riches on 20 Feb 2010 20:11 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? If I somehow enabled cross-filesystem hardlinks is that the same > as current soft-links? I think not." > > But if hardlinks have advantages that soft links don't then at least I have > a case for "somehow" wanting cross-filesystem hardlinks. Of course, this > might be stupid or impossible for other reasons. > > One example that I can think of where hardlinks are essential is: > > I've been doing rsnapshot / rsync differential backups that implicitly rely > on hardlinks unique peoperties. Can't do that with softlinks. Maybe there > are other situations where hardlink's alone will do? There is one big practical difference between a true hardlink and either a normal symlink and the proposed [ uuid, inode] tuple thing. If I make a hard link to an existing file, I (or you) can delete the original file, and my hard link is still there. With either normal symlinks or the [ uuid, inode] tuple thing, it's gone. -- Robert Riches spamtrap42(a)verizon.net (Yes, that is one of my email addresses.)
From: Florian Diesch on 20 Feb 2010 20:43 Robert Riches <spamtrap42(a)verizon.net> writes: > On 2010-02-21, John Hasler <jhasler(a)newsguy.com> wrote: >> Robert Riches writes: >>> 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. >> >> No it wouldn't. A symlink is a file that contains a path in text form. >> >> 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 >> likely that Apple and Microsoft would cooperate. Besides, we already >> have symlinks. > > 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? It would survive moving the files as long as they stay on a file system with the same UUID and changing the mount point of the file systems. But it would make all files on file system inaccessible if I change the file system's UUID. And I'll be really in trouble if I have two file systems with the same UUID (e.g. because I copied one with something like dd). Florian -- <http://www.florian-diesch.de/software/shell-scripts/>
From: unruh on 20 Feb 2010 20:48 On 2010-02-21, Rahul <nospam(a)nospam.invalid> wrote: > Dan Mills <dmills(a)exponent.myzen.co.uk> wrote in > news:4b805f72$0$2533$da0feed9(a)news.zen.co.uk: > >> How do you tell which file systems inode the number refers to? Inodes >> are not unique system wide, only within a single filesystem. > > True. But that's just how the current implimentation is. One could always > use a [ uuid, inode] tuple where the uuid uniquely referred to the foreign > file system. 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. 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? inode numbers are hard-- they are permanantly assigned and if they are lost so is all the data. uuids are soft, they can change. If you made them hard as well, any change would loose you all your data. > > Again, I'm not saying "this ougt to be done" or "this is easy to do" etc. > BUt just trying to figure out how come this "feature" never crept in? Are > there other compelling reasons besides a lack of implimentation not to > allow cross file system hard links? I see several reasons why people might > want cross-FS-hardlinks. > > Another way to put this: Hypothetically, if some smart guy were to try and > write his OS would this be an OK feature? >
From: John Hasler on 20 Feb 2010 20:45 Robert Riches writes: > ...what practical differences would there be from a symlink? None, really. I just said it could be done, not that it would be useful. -- John Hasler jhasler(a)newsguy.com Dancing Horse Hill Elmwood, WI USA
From: John Hasler on 20 Feb 2010 21:13
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. -- John Hasler jhasler(a)newsguy.com Dancing Horse Hill Elmwood, WI USA |