Umm... my suggestion doesn't break anything... but it doesn't fix the issue at hand :)
I have committed the obvious correction (test time stamp equality, not greater than). I think the only way to make further improvements is to use sub-second time info when available, as raster suggests. IMO it's not worth while to test inode, size, etc. too. /Kim On Sat, 19 Mar 2011 05:05:26 +0100, Carsten Haitzler <ras...@rasterman.com> wrote: > On Thu, 17 Mar 2011 11:51:33 +0100 "Jesper Saxtorph" > <jesper.saxto...@prevas.dk> said: > > the problem is - you are BOTH right and BOTH things break something. > suggestion. use things OTHEr than modified timestamp for comparisons. ie > timestamp must EXACTLY match for caching (== not >=), ANd size, and > mode, and > uid and gid, inode... the filesystem may also support (on linux) > nanosecond > resolution: st_mtimensec (see bits/stat.h). thats the only kind of > solution > that will make everyone happy. still not 100% perfect as size may be the > same > and inode re-cycled, and other things the same (als the timestamp > discussion) > BUT if the fs supports nanosecond res timestamps... you are golden... > well > unless the file was written within the same nanosecond :) > >> I understand your thoughts, however I your suggestion will not work. I >> will try to explain it clearer. Bear with me, if it gets a little long >> and I repeat what is written earlier, but I am not sure what part you >> are missing. >> >> In an ideal world where timestamps has infinite precision and they >> represents the actual real time the files has been changed (never future >> timestamps). If this was the case the original code would work fine. >> >> In the real world 3 things can happen to break the setup. >> 1) People can force incorrect timestamps. >> 2) By error files can be marked in the future. If this happens we risk >> that the file will be changed again at the exact time of the timestamp, >> which means 2 writes with the same timestamp. >> 3) The file can be written more than one time with the same timestamp >> because of the timestamp resolution. >> >> Case 1), we should not really care about, as people break the system on >> purpose. >> >> For both case 2) and 3) the problem happen in the following situation: >> a) Imlib reads the file and register the timestamp of the file (for >> simplification I consider this atomic in this example). The file content >> is cached. >> b) The file is changed, but the timestamp is still the same. This can >> happen according to case 2) and 3) above. >> c) Imlib need the file data again and want >> (imlib_image_set_changes_on_disk) to decide if the cached data is valid. >> It checks the timestamp to validate this. However, as the timestamp has >> not changed, the data are deemed valid, while in reality they are not. >> >> Now back to your suggestion. >> What you do is the following: On first load you cache the data. On a >> later load you try test if the files current timestamp is right now. >> >> So lets take an example of why can fail according to case 3): >> I) A file is written at time 17. >> II) The file is read and cached by imlib at time 17. >> III) The file is changed again after the imlib read but still at time >> 17. >> IV) At time 20 imlib need the data again. It try to validate the cache. >> However, since the cache timestamp is still equal to the file timestamp >> and not equal to the current time (20), imlib will validate the cache, >> which is wrong. >> >> You can make a similar scenario for case 2) >> >> I hope this makes it more clear. >> >> -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 >> enlightenment-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel >> > ------------------------------------------------------------------------------ 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 enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
