Re: [9fans] openat()

[moody@posixcafe.org]

[-- Attachment #1: Type: text/plain, Size: 3111 bytes --]

My two cents on this:

What you _would_ want for this would be the ability to walk from the existing fd, however the limits of 9p walk make this a bit impossible to implement in a great way in my opinion. From walk(5):

The fid must represent a directory unless zero path name elements(for just cloning the fid) are specified. The fid must be valid in the current session and must not have been opened for I/O by an open or create message.

Since not every fid is eligible for being walked from, in order to implement opanat() in any way that would be better than just batching the fd2path and open would be to keep a "last directory" associated, like what we do with the string used to open it. Also worth mentioning that fd2path is not without its own problems, it's possible that the namespace has changed since the file has been opened so the same path may not work the second time. So tagging the last directory Chan would be "more correct", but I am not sure how useful this is.

Answering some other comments made:
> As I understand it from the rationale section on the
 linux man page, the call exists to avoid a race condition between 
checking that a directory exists and doing something to a path 
containing it. An additional motivator is providing the effect of 
additional current working directories notably for Linux threads (which 
presumably don't have their own. I think 'threads'  (processes that 
share memory) on Plan 9 do???).

Each process has it's own current working directory:

% pwd
/home/moody
% @{cd /}
% pwd
% /home/moody
> This is all based on the assumption that holding a file/directory open keeps it alive and in existence... which on Plan 9, I think it doesn't, does it? As I understand it, remove can remove a file or directory that is open, which is not like UNIX/Linux...
> 

Depends on the file server implementation, I find that for more synthetic files they are indeed kept alive as long there is someone with a reference to the fid.
This is identifiable if all the cleanup happens on clunks(destroyfid in lib9p), which only happen when a fid's refcount hits zero.

For non-synthetic or more "disk" file servers the behavior can differ. Cwfs does not keep the data around, readers that attempt to read a deleted file, even if they already have a reference open to it will result in a phase error. However 9front's ramfs keeps the data around.



My test for this was as follows:
win1% echo 'something' >/tmp/test
win2% </tmp/test { sleep 10; cat }
win1% rm /tmp/test
# observe the error(if any) on win2

So you really can't assume either case.


Thanks,

moody

P.S.
I apologize for the formatting, it seems my emails are not making it to the list when I attempt to send them from my mail server so I had to copy this response in to the web form.  I would like to figure out why if possible.
------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T675e737e776e5a9c-M8abb414d4890eefbbbe7ef96
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 4135 bytes --]