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