On 15 May, Rusty Ballinger scribbled:
-> > I'm writign a file manager (efm) - when files get "changed" i need to
-> > re-evaluate them - that means if the mime type is image/* re-generate a
-> > thumbnail... and that means openig file, read, generate thumb, write,
-> > display.
-> >
-> > the problem is the change event comes in whilste the file is still
-> > being written it isnt finished yet - and theres no way to know if
-> > someone is activel ywritign to the file- yes - i suppose i could use
-> > fuser and check if tis opened - but it may beopened for read onyl- or
-> > the writes maye be finsihed but the file nto close (maybe a log file of
-> > some sort)
-> >
-> > so beig able tohave events like:
-> > file written at byte 16384 size 4096
-> > file read at byte 300 size 256
-> > etc.
-> > woudl be greta - then at ;eats i could pause the thumbnail generation
-> > until writes have stopped (ie no more write events for that file come
-> > in, and then wait a small amoutn of time after each event comign in
-> > before spawinging the thumbnail generator)
-> >
-> > the problem si some files take a while to writ e- for example saving a
-> > 1024x768 png in gimp actually takes like 3 or 4 seconds.... and some
-> > formats save instantly... so it'd be great to have a way of telling
-> > this.. :) and sicne fam can alreayd tell when when things execute, i'm
-> > sure it probabyl coudl tell me when they read/write :)
->
-> It sounds like what you want to know is not when & where someone writes,
-> but when someone *stops* writing. (So instead of spawning the thumbnail
-> generator on a Changed event, you do it on a "DoneBeingChanged" event.)
->
-> 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.) 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.
->
-> Maybe the right way for this to work is, you spawn the thumbnail generator
-> whenever you get a Changed event, and the first thing the t.g. does is
-> fcntl(fd, F_SETLKW, {F_RDLCK, ...}) the file, and hope that whoever's
-> writing the file was polite enough to lock it while they're writing. That
-> way the t.g. sleeps until the writing process explicitly says "OK, I'm done
-> writing." 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.")
hmm - problem is almost no-one to a tea - except mail clients and mta's
lock files much (or it a suite of apps that use files to share data) so
in general it doesnt tend to work :(
-> --Rusty
->
-> P.S. The problem with imon passing the offset & length of writes to fam is
-> that, in the current implementation, imon doesn't actually know the offset
-> & length. If its hooks into the fs code were rewritten, it would be able to
-> do this, but you'd still have to change the interface between imon & fam,
-> and the fam API, and I think that information still wouldn't tell you when
-> someone was done changing the file.
hmmm ok - well it was just an idea - i do know the kernel knows.. it's
just a matter of perculating the information back into user space -
offset and size isnt really important - thought it coudl see in a
general way that it would be useful to know if you are monitoring a
file - if that part of the file you were looking at changed... maybe
this coudl be put onto a "some daty later" feature list :)
--
--------------- 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
|