On 15 May, Waldo Bastian scribbled:
-> On Mon, 15 May 2000, you wrote:
-> > I don't know of a good way to do this. A not-so-good way for fam to do it
-> > would be if imon reported when a file was opened & closed; fam could then
-> > pass that on to clients. (That would take changes to imon, the interface
-> > between imon and fam, and the fam API. The reason it's not so good is
that
-> > you still have the problem of knowing whether the process that just closed
-> > the file is the same one that was writing to it, whether or not the
writing
-> > process is done, etc.)
->
-> Well, if the file just got created, it is unlikely to be opened by more
than
-> one process. If the file happens to be used as log-file, it can take quite
a
-> while before you get the close-event. Never the less, as a user of fam you
-> have some more possibilities to do what is right for your particular
-> situation.
thats why i was thinkign that fam has kernel hooks - they are exported
by imon - and the kernel knwos when a process does read(0 write()
open() and close() - i suppose the imon patch your attach some parasite
data to any fd a porcess gets fomr am open/close and whenever close()'d
write(0en or read() from it can look at the struct - if imon at the
time has that inode/file in its list to be monitored imon could
generate the event form fam to propagate to clients... i can see that
being possible - the problem is haviung the parasite struct data
attached - that'd be a reasonable bit of work - but still possibl e-
it's somehting the kernel does definitely know and hides fomr
user-space, so making it available would be handy :)
-> > Failing that, a not-so-good way for the client
-> > application to do it would be to always wait a certain amount of time
-> > between the last Changed event on a file and starting the thumbnail
-> > generator on the file, but that's so bad, forget I even suggested it.
->
-> That's what we currently do :-)
hmm - that was my only solution i thought of - but it wasnt that clean
- a bit hackish.. hmmmmmm oh well - looks like its time to give my
timout system a workout again.. :)
-> > [Snap] I like that, but I have no idea how many image-writing processes
-> > are that polite. (I wouldn't be surprised if the answer is "none.")
->
-> In our case, I'm not aware of /usr/bin/install doing that.
not much does - a lot of libs and programs dont expect multiple
processes to be reading the file they are writing at that tim e- mail
programs do (mail spools) but others dont - its just not what
programmers expected.. :(
--
--------------- Codito, ergo sum - "I code, therefore I am" --------------------
The Rasterman (Carsten Haitzler) raster@xxxxxxxxxxxxx raster@xxxxxxxxxxx
raster@xxxxxxxxxxxxxxxxx raster@xxxxxxxxx
raster@xxxxxxxxxx
--
Source code, list archive, and docs: http://oss.sgi.com/projects/fam/
To unsubscribe: echo unsubscribe fam | mail majordomo@xxxxxxxxxxx
|