9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: rsc@plan9.bell-labs.com
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Qid path generation
Date: Mon,  5 May 2003 17:33:20 -0400	[thread overview]
Message-ID: <4c38a7b4efba8dd7467ce1e642996f8a@plan9.bell-labs.com> (raw)
In-Reply-To: <017e01c3134d$66024460$3f00a8c0@MERCURY>

> 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



  parent reply	other threads:[~2003-05-05 21:33 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-05-05 21:29 Andrew Simmons
2003-05-05 21:30 ` W. Josephson
2003-05-05 21:33 ` rsc [this message]
2003-05-05 21:45   ` Andrew Simmons
2003-05-06 11:29     ` Aharon Robbins
2003-05-06  1:09   ` David Presotto
2003-05-06  1:10 ` David Presotto
2003-05-06  1:23   ` Andrew Simmons
2003-05-06  2:29     ` David Presotto
2003-05-06  3:05       ` Russ Cox

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4c38a7b4efba8dd7467ce1e642996f8a@plan9.bell-labs.com \
    --to=rsc@plan9.bell-labs.com \
    --cc=9fans@cse.psu.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).