From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <38c0a7c4dd6a3abb8ba7c2e64d63488c@plan9.bell-labs.com>
From: presotto@plan9.bell-labs.com
To: 9fans@cse.psu.edu
Subject: Re: [9fans] lnfs
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="upas-xknzojvjzqatrbydngnxnuxvga"
Date: Tue,  1 Oct 2002 09:51:16 -0400
Topicbox-Message-UUID: fa38b378-eaca-11e9-9e20-41e7f4b1d025

This is a multi-part message in MIME format.
--upas-xknzojvjzqatrbydngnxnuxvga
Content-Disposition: inline
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

I'm not sure what you mean by flush, fprint is synchronous.
I could retry the write if you like, though there's not
much likelyhood that it would work the second time if
it didn't the first, there's no lock on .longnames,
it's append only, so a failure is probably the fs or
someone having removed the file.

.longnames is also written before the file is created,
so the name should be there should you find the hashed
file when reading the dir.

However, in rreaddir, I don't reread the file while
translating the short names to long ones.  Someone
could create a file while I'm busy converting the
dir.  There's plenty of window there for someone to
sneak through.
--upas-xknzojvjzqatrbydngnxnuxvga
Content-Type: message/rfc822
Content-Disposition: inline

Received: from plan9.cs.bell-labs.com ([135.104.9.2]) by plan9; Tue Oct  1 04:19:15 EDT 2002
Received: from mail.cse.psu.edu ([130.203.4.6]) by plan9; Tue Oct  1 04:19:14 EDT 2002
Received: from psuvax1.cse.psu.edu (psuvax1.cse.psu.edu [130.203.23.6])
	by mail.cse.psu.edu (CSE Mail Server) with ESMTP
	id 3F014199F2; Tue,  1 Oct 2002 04:19:06 -0400 (EDT)
Delivered-To: 9fans@cse.psu.edu
Received: from nigel.9fs.org (cotswold.demon.co.uk [194.222.75.186])
	by mail.cse.psu.edu (CSE Mail Server) with SMTP id 2478719A98
	for <9fans@cse.psu.edu>; Tue,  1 Oct 2002 04:18:50 -0400 (EDT)
Message-ID: <97967b679371324c95efff80d254b753@9fs.org>
To: 9fans@cse.psu.edu
From: nigel@9fs.org
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: [9fans] lnfs
Sender: 9fans-admin@cse.psu.edu
Errors-To: 9fans-admin@cse.psu.edu
X-BeenThere: 9fans@cse.psu.edu
X-Mailman-Version: 2.0.11
Precedence: bulk
Reply-To: 9fans@cse.psu.edu
List-Id: Fans of the OS Plan 9 from Bell Labs <9fans.cse.psu.edu>
List-Archive: <https://lists.cse.psu.edu/archives/9fans/>
Date: Tue, 1 Oct 2002 09:18:49 +0100

Is it expected that lnfs can support several instances of it running
on the same file tree?

It looks that way in that it reloads the the name file before walks
and creates.

But there is no retry around the write of a new entry in newname().
So one instance might create a long named file, and fail to flush it
to .longnames.  Another instance would then not have a translation for
the base32 name it finds in the directory during a walk.

I accept that the windows are small, but I'm searching for an
explanation for some strange behaviour I saw yesterday.

--upas-xknzojvjzqatrbydngnxnuxvga--