Le 29/08/2020 à 11:24, Didier Kryn a écrit :
> Le 28/08/2020 à 15:39, Adam Borowski a écrit :
>> On Fri, Aug 28, 2020 at 08:37:07AM -0400, Hendrik Boom wrote:
>>>>>>>> Is there an establiched word in the Linux/Unix xommunity
>>>>>>>> for something which might be a file or a directory?  
>>>> Therefore it looks to me more like an implementation
>>>> detail than a sensible concept.
>>> I do miss the ability to identify a directory independent of its name.  
>>> It can be important if a directory is renamed and you have active data in 
>>> it.
>>>
>>> There's one directory that works for -- the current directory.  If you 
>>> rename that directory you're still in it.  
>>>
>>> In the 80's or 90's (I forget) there was a proposal to the ISO from 
>>> Japan to establish a standard OS-independent OS interface for 
>>> programmers to use.  I lost against POSIX.
>>>
>>> But it had a machanism whereby opening a file could be done in two 
>>> phases.
>>>
>>> First you get a "lock" on a file.  That gives you a connection to that 
>>> file.  It's not an exclusive kind of lock (unless you ask it to be); 
>>> it's just a way of unambiguously identifying the file as long as it 
>>> exists and you keep the lock.  It hangs on to the file even if someone 
>>> renames it.  (not sure what happens if the file is deleted, though)
>> _Any_ file descriptor does that.  And a deleted file stays there, merely
>> with a 0 link count -- if there's an open descriptor, you can link the file
>> back into the filesystem.  That's even the recommended way to create a new
>> file atomically -- instead of the old write+fsync+rename trick that leaves
>> junk upon a crash.
>     Looks smart. But how do you link the file back? link() and linkat()
> don't take a filedescriptor as input argument for the file. Could you
> please describe the sequence?
>
    OK, got it. the file descriptor can be linked using linkat() with
the flag AT_EMPTYPATH, which tweaks the linkat() API for just that
purpose. I wonder why there isn't a more straightforward API. Good trick
anyway, thanks.

-- 

        Didier


_______________________________________________
Dng mailing list
[email protected]
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Reply via email to