I'm using cfs 1.4.1 from ports on 1.6.1/i386, and have been having
trouble with emacs and auto-save files.  I noticed there is now a
larger cache of filehandles to cfs_fileid (cfs_fh.c:findh does
lookups).  I don't see anything that removes cache entries when files
are deleted, or at least don't understand how this is supposed to work.

My symptoms are that when using emacs in a cfs directory, with
ciphertext in regular local ffs+softdep, auto-saving gets an error
like:

Auto-saving TODO: IO error writing /home/gdt/FOO/BAR/#TODO#: Input/output error

(FOO is a symlink to /crypt/gdt/FOO)

On looking in ciphertext, I find #TODO# to be a symlink, sort of.  ls
-l results in:

ls: ./#TODO#: Invalid argument
lrw-r--r--  1 gdt  users      0 Apr 24 14:52 #TODO#

But I find a zero-length file with that timestamp in the ciphertext.
Waiting a few minutes did not cause this to resolve.  Detaching and
reattaching my cfs filesystem caused #TODO# to appear as a zero-length
file.  So, this really seems like a stale cache entry in cfs, but I'm
not entirely sure - there are lots of layers of caching involved here.

Any clues?


As an aside, I usually try to disable the cache because when using
ciphertext in coda, writes to the server only happen when the file is
actually closed.  So it's important not to translate

  open()/write()/close()

in plaintext into

  open()/write()/wait-a-long-time/close()

since this essentially breaks the semantics the user expects.
But I have not done this for 1.4.1 yet, since I had other problems
with coda and symlinks (see tech-kern thread if you care).