From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <4c38a7b4efba8dd7467ce1e642996f8a@plan9.bell-labs.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Qid path generation
From: rsc@plan9.bell-labs.com
In-Reply-To: <017e01c3134d$66024460$3f00a8c0@MERCURY>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Date: Mon,  5 May 2003 17:33:20 -0400
Topicbox-Message-UUID: 9e84a5fe-eacb-11e9-9e20-41e7f4b1d025

> I'm pondering how to generate unique qid paths for NTFS/FAT32 files. The 2nd
> ed toolset for Windows has a function called "pathqid" which generates a 4
> byte number from the filename. I'd appreciate any hints on the workings of
> this function, particularly the choice of the magic number 1000003, the
> reason for masking with ~CHDIR, and the role of the first parameter, which
> always seems to have 0 passed in - plus any ideas on extending the method to
> 8 bytes, or a better method.

It's just a hash function.

In old Plan 9, the CHDIR bit indicated that the file was a directory.

The extra parameter let you start the hash at a different value,
so that if you knew the hash of a directory, you could compute
the hash of a file within that directory without rehashing the
directory name.

> Also, I would guess that a method such as pathqid could occasionally
> generate the same number from two different file names. Any guesses as to
> the impact of this on a client (eg 9fs)?

It matters when you try to bind or mount on those paths.
Mounts on top of one would also appear on top of the other.
Other programs like cp also use the qids to avoid copying
a file onto itself.  Also, as wkj pointed out, cfs and mount -C
cache based on qids.

I think there might be better ways to get a unique identifier
out of Windows these days.  U9fs, for example, uses the inode
number and device number.  Maybe Windows will let you get at
similar information now.

Russ