From mboxrd@z Thu Jan  1 00:00:00 1970
Date: Fri,  5 Jun 1998 09:12:01 -0400
From: Srinivas.Narendula@libnet.com Srinivas.Narendula@libnet.com
Subject: [9fans] reuse of values of qid.path
Topicbox-Message-UUID: 795be0d8-eac8-11e9-9e20-41e7f4b1d025
Message-ID: <19980605131201.HQUeceRVisnrsyeS8rV8JqxW6BPKr4zzrjDGT1jvT5o@z>







How important is it to not reuse old values of qid.path?

The current fileserver uses sb->qidgen to give a new file/dir
a new path value, but allows duplicates since there is no
handling of overflow.  There is a "check" command option called
"setqid" to resequence the qids if qidgen is in danger of overflow,
but was not implemented.

Having two files/directories with the same qid.path is a "bad thing",
but is possible in the current system.

It seems that qid.path is used like an inode number (and in fact is
the device and inode number in u9fs).  If that is the case, then
instead of using qidgen, use the block address of the directory
block shifted by the size of the slot and or'ed with the slot.

qid.path = (p->addr << log2(DIRPERBUF)) | (slot % DIRPERBUF);

The only problem is that the sequence:

    cp file_of_size_x a
    rm a
    cp different_file_of_size_x a

would result in the two files having the same qid and so would

    cp file_of_size_x a
    rm a
    cp different_file_of_size_x b

but

    cp file_of_size_x a
    cp different_file_of_size_x a

would not (since cp does a truncate before a create).

So again, how important is that?

David Butler
gdb@dbSystems.com