* [9fans] 9p questions
@ 2003-07-23 11:13 steve.simon
2003-07-23 14:59 ` rog
0 siblings, 1 reply; 3+ messages in thread
From: steve.simon @ 2003-07-23 11:13 UTC (permalink / raw)
To: 9fans
Hi,
two questions about 9p semantics:
1/
Netware will not let me rename a file which is open.
So, when wstat updates a file's name does 9p place a
restriction on wether the file is open or not?
Do I have to do a close, rename and reopen on rename
or is just close safe? I guess the answer is reopen
the file - more races :-(
Netware has similar restrictions on deleteing files/dirs so
I am closing then also, but I cannot imagine any side
effects from this.
2/
Netware changes its file ID (which I map to Qid) when
a file is renamed.
Using lib9p is it OK to change fid->qid in wstat, under the
libraries feet so to speak?
Also, will it mess up plan9 clients?
-Steve
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [9fans] 9p questions
2003-07-23 11:13 [9fans] 9p questions steve.simon
@ 2003-07-23 14:59 ` rog
0 siblings, 0 replies; 3+ messages in thread
From: rog @ 2003-07-23 14:59 UTC (permalink / raw)
To: 9fans
> So, when wstat updates a file's name does 9p place a
> restriction on wether the file is open or not?
no - you can wstat whether the file is open or not (fwstat, wstat).
you could always return an error if a rename was attempted when the
file was open. presumably the file can be currently open by another
user, so i'd assume doing a close/rename/reopen is unlikely to be
sufficient in general.
i don't know if much plan 9 infrastructure relies on being able to use
fwstat to rename a file (the most likely candidate, upas, doesn't use
fwstat to rename the mbox, but then again it might easily be holding
another fd open on it).
> Netware has similar restrictions on deleteing files/dirs so
> I am closing then also, but I cannot imagine any side
> effects from this.
remove is a clunk anyway, so no problems there (apart from
if another process has it open, as above, but nothing you can
do there).
> Using lib9p is it OK to change fid->qid in wstat, under the
> libraries feet so to speak?
this is fairly dodgy; the only times AFAIK that a qid corresponding
to a fid can be changed are attach, create, open and walk,
and all these return the new qid in the rmsg.
> Also, will it mess up plan9 clients?
good question...
'cos i know it's difficult verging on impossible to manufacture a
proper qid space for some imported filesystems.
i know that inferno used a hash of the filename for its ntfs
filesystem under windows for quite a while, and most things worked ok.
i think it still does the same thing, with the exception that a file
which has been walked to keeps the same qid for as long as there's a
reference to it.
this ensures that a bind onto a directory stays put even though the
directory has been renamed, but it's not perfect. i may be wrong
about this too, as i didn't have anything to do with the changes.
cheers,
rog.
^ permalink raw reply [flat|nested] 3+ messages in thread
[parent not found: <599525253@snellwilcox.com>]
end of thread, other threads:[~2003-07-23 15:15 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-07-23 11:13 [9fans] 9p questions steve.simon
2003-07-23 14:59 ` rog
[not found] <599525253@snellwilcox.com>
2003-07-23 15:15 ` steve.simon
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).