> -----Original Message----- > From: Kim Woelders [mailto:[email protected]] > Sent: 6. marts 2011 07:50 > To: [email protected]; Jesper Saxtorph > Subject: Re: [E-devel] imlib2 caching can fail > > On Thu, 03 Mar 2011 15:46:15 +0100, Jesper Saxtorph > <[email protected]> wrote: > > > I have just submitted a bugraport + a patch on trac (bug #716). > > > > I just wanted to notifify it here also as I do not know the > > enlightenment community and how it works. > > > Either is fine. > > > To repeat my bug report: > > "I use imlib2 as a image library in a project. However the use we have > > sometimes tricker a situation where imlib2 uses an invalid cache. > > > > imlib2 uses timestamps to test if a image cache i valid. If a files > > modification time is in the future it is not possible to use validation > > scheme. Further if the timestamp is equal to now, we do not know if the > > modification time is in the future or not. The result is that the cache > > should be invalidated for file timestamps >= now. > > An example of a problematic situation: timestamps are in whole seconds > > times given as here as seconds: > > time=32.1 : image.png is written by someone > > time=32.4 : image.png is loaded by imlib2 > > time=32.5 : image.png is written with new data > > The situation is now that the cache has the same timestamp as the file, > > but the content is not the same. > > > > A possible fix is a 3 line patch, which I have attached. It invalidate > > the cache if the files timestamp is >= now. > > The patch is made agains head, however, the image.c file (where the > > patch is applied) has changed very little in it lifetime, so it works > > fine with earlier versions of imlib2 (I use it against 1.4.2)." > > > > I attached an incorrect patch at first to the ticket, but have submittet > > the correct afterwards. Sorry for that. > > > > My suggestion to a patch (I have made the long comment as I think it is > > not obvious why it is needed): > > --- imlib2/src/lib/image.c.orig 2011-03-03 14:23:49.000000000 +0100 > > +++ imlib2/src/lib/image.c 2011-03-03 14:45:19.000000000 +0100 > > @@ -1017,6 +1017,18 @@ > > im->key = __imlib_FileKey(file); > > } > > im->moddate = __imlib_FileModDate(file); > > + /* If the file modify time is now or in the future, we can not make > > a */ > > + /* cache. */ > > + /* One of several possible scenarios: */ > > + /* time=now: file is written by someone */ > > + /* time=now: file is loaded here */ > > + /* time=now: file is written again by someone */ > > + /* Now we have a file a timestamp equal to our cache, but with a */ > > + /* different content. */ > > + if (im->moddate >= time(NULL)) > > + { > > + dont_cache = 1; > > + } > > /* ok - just check all our loaders are up to date */ > > __imlib_RescanLoaders(); > > /* take a guess by extension on the best loader to use */ > > > > Hope it make sense, otherwise feel free to ask and/or discuss it > > > I see there is a problem, but I don't think it is the proper solution. > If you have a file with a "now"/future time stamp it would never be > cached, which is wrong.
Unless I made a mistake, my suggestion should result in the following: If the timestamp is "now"/future, then we will not chache the file this time. However, next time we need the file, it will be cached (unless it has changed so we are in the same situation again). Note that dont_cache is a function parameter and hence a local variable, so the change is not persistent. > How about in stead changing line 986 (svn) to check whether the time stamp > has changed in stead of checking if it is newer? > > /Kim Basically your suggestion will not change the problem. In my example, the timestamp has not changed, however, the file has. Further, if the timestamp is in the future and we cache it, we have a problem if the file is changed when the current computer time reach the time the file has. For files with stamp "now"/future we can verify a file has changed if the timestamp has changed, but we can not verify that the file has not changed if the timestamp has not changed. -Jesper ------------------------------------------------------------------------------ Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
