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: Florian Diesch on 22 Feb 2010 20:54 John Hasler <jhasler(a)newsguy.com> writes: > 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 But then creating a new lock file isn't atomic anymore as you have to check for the existence of multiple files or read the directory contents before you create a new one. Florian -- <http://www.florian-diesch.de/software/pdfrecycle/>
From: John Hasler on 22 Feb 2010 21:21 I wrote: > That same data can be stored in the name of an empty ordinary file. Florian writes: > But then creating a new lock file isn't atomic anymore as you have to > check for the existence of multiple files or read the directory > contents before you create a new one. From the open() man page; O_EXCL Ensure that this call creates the file: if this flag is specified in conjunction with O_CREAT, and pathname already exists, then open() will fail. Obviously this only works for the simplest sort of lockfile but it has been used successfully for decades. -- John Hasler jhasler(a)newsguy.com Dancing Horse Hill Elmwood, WI USA
From: Jerry Peters on 23 Feb 2010 16:20 despen(a)verizon.net wrote: > 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. The catalog implements a simple hierarchical filesystem on datasets. Think of the catalog(s) as a sort of simplified directory structure. Without the catalog structure you'd need to specify at least a volser and probably a unit in addition to the dsname and disposition for all dataset references. Jerry
From: Jerry Peters on 23 Feb 2010 16:22 John Hasler <jhasler(a)newsguy.com> wrote: > 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. > Are you sure? References? Jerry
From: Florian Diesch on 24 Feb 2010 16:16
John Hasler <jhasler(a)newsguy.com> writes: > I wrote: >> That same data can be stored in the name of an empty ordinary file. > > Florian writes: >> But then creating a new lock file isn't atomic anymore as you have to >> check for the existence of multiple files or read the directory >> contents before you create a new one. > > From the open() man page; > > O_EXCL Ensure that this call creates the file: if this flag is > specified in conjunction with O_CREAT, and pathname > already exists, then open() will fail. > > Obviously this only works for the simplest sort of lockfile but it has > been used successfully for decades. It usually doesn't help if data is stored in the file name as in that case the new file name is most likely different from the old one and you often don't even know the old file name and have to search for a possible existing old lock file first before calling open(). Florian -- <http://www.florian-diesch.de/software/pdfrecycle/> |