[9fans] QTEXCL/DMEXCL redundancy

[9fans] QTEXCL/DMEXCL redundancy

[Pavel Klinkovsky]

Hi all,

first time I am trying to create a "synthetic" file system.

I want to have "synthetic" files with the exclusive flag.

In my getdirent (called from dirread9p) function I have:

>d->qid = (Qid){n, 0, QTFILE|QTEXCL};
>d->mode = 0666;

This does not work (ls -l did not show 'l' flag).


When I made a modification:

>d->qid = (Qid){n, 0, QTFILE|QTEXCL};
>d->mode = DMEXCL|0666;

This works (ls -l shows 'l' flag).


I thought the DMEXCL in 'mode' is a unnecessary since QTEXCL is already present in 'Qid'. I was apparently wrong...

Can you recommend me e.g. the manual page or document explaining such matter?
I really do not understand why such a redundancy (QTEXCL/qid and DMEXCL/mode) is there...

Thanks.

Pavel

Re: [9fans] QTEXCL/DMEXCL redundancy

[Charles Forsyth]

The qid.type is defined to be the top 8 bits of the mode.
See the end of intro(5) and the discussion in stat(5).

On 5 December 2012 09:41, Pavel Klinkovsky <pavel.klinkovsky@gmail.com> wrote:
> I really do not understand why such a redundancy (QTEXCL/qid and DMEXCL/mode) is there...

Re: [9fans] QTEXCL/DMEXCL redundancy

[Charles Forsyth]

The reason for having those bits in the qid.type is because the qid is
returned on open,
allowing (say) caching programs to discover directory/not
append-only/not and other details
without needing another transaction (and a race) to stat the file.

On 5 December 2012 11:01, Charles Forsyth <charles.forsyth@gmail.com> wrote:
> The qid.type is defined to be the top 8 bits of the mode.
> See the end of intro(5) and the discussion in stat(5).
>
> On 5 December 2012 09:41, Pavel Klinkovsky <pavel.klinkovsky@gmail.com> wrote:
>> I really do not understand why such a redundancy (QTEXCL/qid and DMEXCL/mode) is there...

Re: [9fans] QTEXCL/DMEXCL redundancy

[Pavel Klinkovsky]

Thank you for the explanation.

Pavel

Re: [9fans] QTEXCL/DMEXCL redundancy

[erik quanstrom]

On Wed Dec  5 06:03:50 EST 2012, charles.forsyth@gmail.com wrote:
> The reason for having those bits in the qid.type is because the qid is
> returned on open, allowing (say) caching programs to discover
> directory/not append-only/not and other details without needing
> another transaction (and a race) to stat the file.
>

i couldn't find a single program that takes advantage of this.

- erik

Re: [9fans] QTEXCL/DMEXCL redundancy

[Charles Forsyth]

cfs, fscfs

On 5 December 2012 12:39, erik quanstrom <quanstro@quanstro.net> wrote:
> i couldn't find a single program that takes advantage of this

Re: [9fans] QTEXCL/DMEXCL redundancy

[erik quanstrom]

On Wed Dec  5 08:07:03 EST 2012, charles.forsyth@gmail.com wrote:
> cfs, fscfs

; cd /sys/src/cmd/cfs
; g EXCL
; 9diff *
post...
;

- erik

Re: [9fans] QTEXCL/DMEXCL redundancy

[Charles Forsyth]

I was explaining why the top bits of the mode were in qid.type
(replacing the older single bit directory flag at the top of
qid.path).
I wasn't saying which of those were important to which applications.
You could, of course, not bother to put QTEXCL in that set
specially, and then have special cases to cope with that. On the whole
(a) QTEXCL might also be useful even if cfs doesn't use it;
(b) it's easier to write and explain qid.type == (mode>>24) than to
enumerate special cases.


On 5 December 2012 13:45, erik quanstrom <quanstro@quanstro.net> wrote:
> On Wed Dec  5 08:07:03 EST 2012, charles.forsyth@gmail.com wrote:
>> cfs, fscfs
>
> ; cd /sys/src/cmd/cfs
> ; g EXCL
> ; 9diff *
> post...
> ;
>
> - erik
>