OpenEuphoria

2. Re: Rob: Q: dir() + flaw discovered with time stamps

• Posted by Robert Craig <rds at RapidEuphoria.com> Feb 15, 2006
• 581 views
• Last edited Feb 16, 2006

Vincent wrote:
> Rob,
> I hate to bother you with this but I just discovered a potential flaw with the
> current dir() method used with the include system. It can be taken care of but
> requires futher enhancement to dir(). This isn't critical, but it has the
> potential
> to reduce accuracy alot more often than I'd like.
> 
> Let me explain:
> 
> It seems that when I download ZIP or TAR files from the archive and extract
> them to my compuer, all the files' time stamps change to exactly the same.
> Whats
> awkward though is different parts of the stamps change with different
> extraction
> software.
> 
> Example:
> 
> When I extract a ZIP file using Windows XP's default ZIP extraction utility
> with "Extract All", it will change the "Modified" and "Accessed" stamps to
> exact
> the same current time and date; the "Created" stamp isn't effected. However
> when I use WinRAR to extract, the "Created" and "Accessed" stamp is affected
> on all the extracted files but not "Modified".
> 
> This is an issue because dir() returns the "Modified" time-stamp and if in one
> case all the extracted files have their "Modified" stamp changed to the exact
> same date and time, then it will effectively reduce accuracy with duplicate
> file detection in IncludePush(). What this means is that the accuracy will now
> only be filename, attribute, and filesize. The problem is this can be a common
> occurance if extracted a certain way.
> 
> I cannot explain this behavior but will note that if a "Created" time-stamp
> was added into the dir() result, it should bypass the issue. If one stamp is
> changed to exactly the same, it could rely on the unaffected stamp for
> additional
> accuracy and visa versa.
> 
> My question is how difficult would it be to add a "Created" time-stamp set
> into
> the dir() result on all platforms? What about an "Accessed" time-stamp set?
> Perhaps you could add both for completeness and even higher overall accuracy?
> 
> Doing this will also make needing to enhance dir() in the foreseeable future
> unnescesary. I bet if you knew this before, you wouldn't have implemented the
> include fix. But please don't take it away, just add another time-stamp set
> or two to the bottom of the dir() result.
> 
> So now maybe dir() would return this info in this order:
> 
> 1) file name
> 2) attribute
> 3) byte size
> 
> 4) year modified
> 5) month modified
> 6) day modified
> 7) hour modified
> 8) minute modified
> 9) second modified
> 
> 10) year accessed
> 11) month accessed
> 12) day accessed
> 13) hour accessed
> 14) minute accessed
> 15) second accessed
> 
> 16) year created
> 17) month created
> 18) day created
> 19) hour created
> 20) minute created
> 21) second created
> 
> Or perhaps leave out the "Accessed" time-stamp?

I just tried WinZip and pkunzip.
They keep the "last modified" time stamps the way they 
were in the .zip file. No problem.
I just tried tar on Linux. It also keeps the last modified
dates the way they were in the .tar file.
So I don't think the problem is as big as you suggest.
I might eventually add some more information to the dir() results,
but I don't think this is an urgent problem.

In some cases, the person who made the .zip may have 
caused a lot of files to be set to the same time stamp
before zipping them. For example, I create the euphoria\source 
directory by running a program that copies the files from 
my main source directory, stripping out a few bits 
(translator/binder related, or old de-shrouder). In this case
you would hope the person making the .zip would do some
final testing before zipping. The bug you are thinking
about would not, IMHO, be likely to be introduced 
just because of zip/unzip.

Regards,
   Rob Craig
   Rapid Deployment Software
   http://www.RapidEuphoria.com