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 22 Feb 2010 18:25 Marten Kemp <marten.kemp(a)thisplanet-link.net> wrote: > Rahul wrote: >> Marten Kemp <marten.kemp(a)thisplanet-link.net> wrote in news:hlrcc1$720$1 >> @speranza.aioe.org: >> >>> Cross-FS-hardlinks could be special entries containing the volser >>> where the FS is to be found and the inode within the FS. >>> >>> I'd be willing to wager that cross-FS-hardlinks weren't implemented >>> because that would create a special type of pointer. >> >> Now that's an interesting line of thought: Are cross-FS hardlinks frowned >> upon in most other OS's too besides Linux? How about other *nix es? Or even >> totally different OS's. > > zVM doesn't have multi-volume user file systems[0]; neither does > zOS (except possibly for TEMP files), in my limited and quite > outdated knowledge. Actually I'd say that zOS does does have a multi-volume filesystem. The catalog structure creates a sort of limited hierarchical filesystem. All links are via volser and dataset name, so I suppose they'd be considered soft or symlinks. Jerry > > I don't know enough about OS400 to make a guess. > > [0] Well, there's the Shared File System but that's more > like a LVM 'volume.' >
From: Jerry Peters on 22 Feb 2010 18:28 John Hasler <jhasler(a)newsguy.com> wrote: > Robert Heller writes: >> No. > > Creating an empty file is an atomic operation. There no need to write > anything to it. > >> And merely touching the file stores no information. > > It stores the file name. Creating an empty file as a lock is commonplace. > >> Creating a symlink to 'nowhere' not only creates the link, it also >> creates the path-like datum *at the same time*. > > That same data can be stored in the name of an empty ordinary file. The > advantage of using a symlink is that it can (if short) be stored > entirely in the directory, thus saving an inode. I thought short symlinks were stored in the inode by using the space normally occupied by the various data block pointers. Thus avoiding the need to read the data. Jerry
From: Jerry Peters on 22 Feb 2010 18:31 Rahul <nospam(a)nospam.invalid> wrote: > 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? The *filesystem* assumes that a dangling hard link is an error, applications really have no input to the matter. Jerry
From: John Hasler on 22 Feb 2010 18:58 Jerry writes: > I thought short symlinks were stored in the inode by using the space > normally occupied by the various data block pointers. Yes, but if they are shorter yet they are stored entirely within the directory entry. -- John Hasler jhasler(a)newsguy.com Dancing Horse Hill Elmwood, WI USA
From: despen on 22 Feb 2010 19:59
Jerry Peters <jerry(a)example.invalid> writes: > Marten Kemp <marten.kemp(a)thisplanet-link.net> wrote: >> Rahul wrote: >>> Marten Kemp <marten.kemp(a)thisplanet-link.net> wrote in news:hlrcc1$720$1 >>> @speranza.aioe.org: >>> >>>> Cross-FS-hardlinks could be special entries containing the volser >>>> where the FS is to be found and the inode within the FS. >>>> >>>> I'd be willing to wager that cross-FS-hardlinks weren't implemented >>>> because that would create a special type of pointer. >>> >>> Now that's an interesting line of thought: Are cross-FS hardlinks frowned >>> upon in most other OS's too besides Linux? How about other *nix es? Or even >>> totally different OS's. >> >> zVM doesn't have multi-volume user file systems[0]; neither does >> zOS (except possibly for TEMP files), in my limited and quite >> outdated knowledge. > > Actually I'd say that zOS does does have a multi-volume filesystem. > The catalog structure creates a sort of limited hierarchical > filesystem. > All links are via volser and dataset name, so I suppose they'd be > considered soft or symlinks. No, neither. The z/OS files can be allocated multi-volume but I don't see how that single file can be considered a hard of soft link. z/OS has some limited aliasing capability for datasets and members of a PDS/PDSE. z/OS also has UNIX style files that operate just like any other UNIX filesystem. |