On Wed, Jun 06, 2007 at 01:01:30AM +0200, Mael Hilléreau wrote: > Le 6 juin 07 à 00:40, Andre Poenitz a écrit : > > >On Wed, Jun 06, 2007 at 12:37:31AM +0200, Mael Hilléreau wrote: > >>Le 6 juin 07 à 00:23, Andre Poenitz a écrit : > >> > >>>>It would make sense to compute checksum only if the timestamp is > >>>>different: it then saves the conversion process in the case no new > >>>>modifications exist (i.e. the file was saved but not modified). > >>> > >>>That assumes that changed files cannot have the same time stamp. > >>>Even if that might hold true in most cases > >>>POSIX guarantees only 1 sec resolution, FAT has 2 IIRC. > >>> > >>>One can have tons of changes in that time.... > >> > >>??? > >>I think you're incredibly productive if you can modify AND save a > >>graphic file more than one time per second! > > > >We are talking about automated conversion, aren't we? > > I thought we were talking about automated conversion arising after a > manual external file modification. But if not, could you explain > further? > > >!! But if we suppose that, > >>then you won't care to wait the next second for a screen update to > >>come up ;) > > > >Is it only screen update, or is it also correctness of conversion? > > This was joking. Nevertheless, IMHO the timestamp is a good solution > for almost 99,9999% of time. The remaining 0,0001% being outdated > screens, unless you can compile/modif/save/recompile in less than 1 > sec... (however, assuming that file formats are different for on > screen preview and for output...) > > Anyway, we may agree that when dealing with graphics, the CRC should > only be computed when timestamps are identical, do we?
Not sure. Different timestamps and equal contents might be possible in which case it'd probably be not the worst solution to do nothing. Andre'
