From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <152675e3de6a7d0fe4740c7855b3d9d5@plan9.bell-labs.com>
From: presotto@plan9.bell-labs.com
To: 9fans@cse.psu.edu
Subject: Re: [9fans] lnfs(1)
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Date: Wed, 10 Jul 2002 23:22:03 -0400
Topicbox-Message-UUID: c8cdd386-eaca-11e9-9e20-41e7f4b1d025


On Wed Jul 10 22:54:41 EDT 2002, okamoto@granite.cias.osakafu-u.ac.jp wrote:
> I'm now using kfs system, and have a question on lnfs(1).
> 
> term% cd /usr/sys
> term% mkdir 大阪府大地学教室岡本健二
> can't create 大阪府大地学教室岡本健二:  name too long
> 
> Yes, I know it, then
> term% lnfs /usr/sys
> term% mkdir 大阪府大地学教室岡本健二
> Ok!, good, I see 大阪府大地学教室岡本健二 directory.
> term% cat .longnames
> 大阪府大地学教室岡本健二
> 
> Then,
> term% rm 大阪府大地学教室岡本健二
> Ok, dir 大阪府大地学教室岡本健二 has been removed.
>  However,
> term% cat .longnames
> 大阪府大地学教室岡本健二
> still shows the removed directory name.
> 
> term% disk/ksync
> term% cat .longnames
> 大阪府大地学教室岡本健二
> 
> then, I killed the lnfs process.
> Then, I cannot access /usr/sys directory anymore...
> 
> What I did wrong?
> 
> Kenji
> 

Nothing ever gets removed from .longnames.  However, removing
the file does get rid of it and you won't see it in a subsequent
ls.  If you want to change lnfs to garbage collect the .longnames
file, go right ahead.  I didn't think it was worth is since its
just a stopgap till seanq and jmk get the next file server working
but if you're going to be using it heavily...

In case you haven't looked at the code, .longnames is just a set of
possible long names.  When you try to open a long name under lnfs's
mount point, .longnames doesn't even get used.  lnfs just tries
to open the real file whose name is the first 26 characters of
the base64 encoding of the sha1 hash of the long name.  .longnames
just gets used to translate the names from sha1's to strings
when you read a directory.  If the possibility of an accidental
hit in sha1 is ~ 2^80, then this will be ~ 2^32 since we are only
encoding about 65 of the 160 bits.  This assumes a linearity that
I'm not sure exists in sha1.  Not wonderful odds but fine for a
stopgap.

Also, in case you haven't noticed, it allows spaces in the names:

% lnfs drafts
% > drafts/'spaces in file names  suck'
% echo drafts/spa*
drafts/spaces in file names  suck
% ls drafts/spa*
'drafts/spaces in file names  suck'

Hence, all mail threads fill the same well needed void.