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: Rahul on 20 Feb 2010 19:36 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. 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? -- Rahul
From: Rahul on 20 Feb 2010 19:38 Grant Edwards <invalid(a)invalid.invalid> wrote in news:hlpf6m$s6j$1 @reader2.panix.com: > If you launch her through a double-slit setup, isn't it > possible for her to pass through _both_ her house and your > house? Are "entangled nieces" a possibility? -- Rahul
From: Rahul on 20 Feb 2010 19:47 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. -- Rahul
From: John Hasler on 20 Feb 2010 19:47 Rahul writes: > How about a uuid as the identifier? You'd have to standardize the format and location over all filesystems. And what would you do about the fact that you can mount a filesystem wherever you want to? -- John Hasler jhasler(a)newsguy.com Dancing Horse Hill Elmwood, WI USA
From: Robert Riches on 20 Feb 2010 20:09
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? -- Robert Riches spamtrap42(a)verizon.net (Yes, that is one of my email addresses.) |