[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

question about updating dir



I was playing with Inferno the other day and had a dir window open on a 
directory, and was gaily dragging and dropping files into notepad to look at 
them when I found one that I wanted to delete.  I typed "rm file" in a shell 
window, and the file dutifuly disappeared.

But not in the dir window! on perusing dir.b it appears that the contents of 
the window are only recomputed when the window changes size or you ask for a 
different sorting key.

This seems wrong; when a file is deleted it should disappear. In Unix and 
plan-9's shell/command line oriented view of the world the old behavior was 
fine, since you'd do 'ls' and then something and then 'ls' again, not 
expecting the old text in the glass tty window to change magically.  THis 
graphic paradigm seems to demand more tightly integrated behavior.

If folks agree, the question becomes "how do we tell dir that a file is gone?"

One option is to have dir listen to a channel for messages that files are dead 
-- perhaps it could export a "filesystem" and rm could write a message into 
the file for the directory it was removing from.  This would work OK for rm 
and dir, but other programs remove files too.  Whatever scheme we come up with 
should work for any way files get deleted (or changed; or created!  How nice 
to chmod +x a file and see its icon change in the other window...)

The best thing I've been able to come up with, which I don't like, is for dir 
to periodically stat the directory (perhaps in a separate thread, 
communicating back to the main window thread through a channel), and reread it 
if it changes.  

There doesn't seem to be way of registering a filesystem callback along the 
lines of "dear kernel, please arrange for this {signal to be sent/routine to 
be called/whatever} when event {directory changed/file removed} occurs."

Does anyone have a better idea?  Should something like watchdogs go into the 
inferno (or any other) filesystem?  Or is this the start down the slippery 
slope that gave us SVR4? Does someone want to explain that I'm completely 
wrong <grin>.

  --berry

Berry Kercheval :: kerch@parc.xerox.com :: Xerox Palo Alto Research Center