On Sun, 20 Mar 2011 18:21:44 +0100 "Kim Woelders" <[email protected]> said:
well that was kind of my point :) it's broken currently in 1 situation (file modified within the same second). checking for size and inode number MAY also help as writing a new file may use a new inode and be of different size, so it's "less likely" to be a problem. if it re-uses the same inode and is exactly the same size, then sub-second timestamp will help (if OS supports that). i actually put this into evas on the weekend. imlib2 is still in limbo atm. > 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 > <[email protected]> wrote: > > > On Thu, 17 Mar 2011 11:51:33 +0100 "Jesper Saxtorph" > > <[email protected]> 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 > >> [email protected] > >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > >> > > > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [email protected] ------------------------------------------------------------------------------ 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
