Subject: Re: "knowing" when a file is available in a directory
To: Bill Sommerfeld <sommerfeld@orchard.arlington.ma.us>
From: Eric McWhorter <emcwhorter@xsis.xerox.com>
List: port-i386
Date: 10/06/1999 10:15:07
Bill Sommerfeld writes:
 > > Not being especially familiar with the NetBSD kernel, could someone
 > > tell me if there is a way to get some sort of notification in a
 > > userland process from the kernel that a new disk file has been
 > > created?  I could hack some system call in some kludgy way, but I'd
 > > probably do something wrong and I'm hoping there's already some sort
 > > of hook for this sort of thing.
 > 
 > Just to understand what you're doing..
 > 
 > You're looking for files to be created in a particular directory?
 > and you have some sort of protocol so that partially-created files
 > won't be mistaken?

Yes to files in a particular directory.  I was just being sloppy when
I said create.  I meant "once a file has been created" rather than
open(2) with O_CREAT.  Someone pointed out in a private email that
what I probably really want is to hook close(2), which I think is
true.  Of course, I really just want close(2) when the deleted
descriptor referred to a plain file.

 > About the only existing hook for this is the ktrace interface, but
 > that's definitely overkill.

Blech.

 > How quickly do you need detect the new file?  you could poll once a
 > second for a change in modification time on the directory.  On a local
 > filesystem it shouldn't be too painful..

As things are, the printer will outrun any single CPU computer by a
fair margin, so any idle time on the computer is categorically a bad
idea.  Also, polling on a one second interval would limit the printer
to (an upper bound of) 60 print jobs a minute, which would be too
slow.

 > Another possibilty is if you provide the "filesystem" (e.g., via some
 > sort of hack to the portal filesystem).

I read the first page of a document on portalfs and it mentioned a
daemon.  If I read that right, then I think the overhead would be too
high and I'd probably get better performance by getting the receiving
process to somehow cooperate.  Good suggestion, though.  I will
back-burner some portalfs experiments.

-- 
Eric McWhorter
Xerox Special Information Systems
emcwhorter@xsis.xerox.com