From: Ken H. <ke...@ha...> - 2006-01-18 17:37:28
|
Keith Warno wrote: > * <ke...@ha...> [17/01/2006 1417EST]: > >>It would seem that the thumbnail code would have to detect when the >>image was opened for writing and defer creating the thumbnail until >>the file was closed. Is this possible with dnotify? I'm pretty sure >>it is with inotify, but Filer isn't using inotify yet AFAIK. > > > Correct. I don't see a mention of inotify in the code, just dnotify. I > don't know anything about the inotify API; any idea how tough it would > be to add? > It doesn't appear too difficult. One problem is that it just made it into mainline kernel, or is only available as patches. So dnotify would have to stay too. But to add the new functionality would require additional Filer work to take advantage of inotify's API. Another thought is to add DN_MODIFY to the dnotify flags, so the Filer would know when a file was modified, vs created/deleted/renamed. Then we could trigger a thumbnail update - but that could mean several thumbnail updates for one copy operation, unless someone could figure out how to defer the update until the copy was finished. Hmm, another thought occurred to me. If the file is being modified during the copy, then after it is done, shouldn't the modified time be newer than the thumbnail creation time? Shouldn't a refresh pick this up and update the thumbnail? I can see that doing a 'touch *' on a dir of images DOES trigger a refresh. It might be that due to the particular logic of how the copy is done, that even inotify wouldn't solve it. |