OpenEuphoria

Re: Other information and dates of an archive

• Posted by CChris <christian.cuvier at agriculture.gouv.fr> Feb 02, 2007
• 580 views

ZNorQ wrote:
> 
> CChris wrote:
> > 
> > Sergio Gelli wrote:
> > > 
> > > CChris wrote:
> > > > 
> > 
> > > Hello CCris,
> > > 
> > > Your code is very beyond what I can understand.
> > > 
> > > I tried to make it to run, but it is impossible.
> > > 
> > > You can explain better?
> > > 
> > > Many Thanks,
> > > 
> > > Sérgio - Brasil
> > 
> > Completed with some missing statements and a few comments. I am using 
> > Windows API directly since I don't know which wrapper library you use.
> > Additionally, this code won't work on any other plaform than Windows.
> > 
> > }}}
<eucode>
> > -- wrap a few functions from kernel32.dll
> > constant kernel32=open_dll("kernel32.dll"),
> > gft=define_c_func(kernel32,"GetFileTime",repeat(C_POINTER,4),C_BOOL),
> >
> > ft2st=define_c_func(kernel32,"FileTimeToSystemTime",repeat(C_POINTER,2),C_BOOL),
> > cf=define_c_func(kernel32,"CreateFileA",repeat(C_POINTER,7),C_POINTER),
> > ch=define_c_func(kernel32,"CloseHandle",{C_POINTER},C_BOOL),
> 
> C_BOOL isn't a legal type, I used C_LONG - would that be ok?
> 
> > -- reserving some memory
> > mem_area=allocate(72),
> > -- area for raw data
> > create_time=mem_area,
> > last_access=mem_area+8,
> > last_write=mem_area+16,
> > -- area for usable data
> > system_create_time=mem_area+24,
> > system_last_access=mem_area+40,
> > system_last_write=mem_area+56,
> > -- this flag is used later: it tells the OS to fail upon opening a file
> > -- which doesn't exist
> > OPEN_EXISTING = 3
> > 
> > sequence fname
> > fname="C:\my_file.txt") -- set this to the actual file name
> > atom hfile
> > integer rc
> > -- set hfile to a handle on your file
> > hfile=c_func(cf,{allocate_string(fname), 
> >                  0, 
> >                  0, 
> >                  0, 
> >                  OPEN_EXISTING,
> >                  0, 
> >                  0})
> > if not hfile then
> > -- something went wrong, do something useful here
> > end if
> > -- now we have a file handle, let's get the timestamps
> > -- you may wish to check if rc=0, which notifies of an error
> > rc=c_func(gft,{hfile,create_time,last_access,last_write)
> > -- convert the data to something of use. Again, rc=0 means soething went
> > wrong
> > rc=c_func(ft2st,{create_time,system_create_time})
> > rc=c_func(ft2st,{last_access,system_last_access})
> > rc=c_func(ft2st,{last_write,system_last_write})
> > -- now close the file
> > rc=c_func(ch,{hfile})
> > </eucode>
{{{

> > 
> > Now the data is available to be peek()ed at system_create_time,
> > system_last_access and system_last_write respectively.
> > Each of the three 16 bytes area is made of 8 fields 2 byte long each.
> > They come in the following order:
> > * Year
> > * Month
> > * DayOfWeek
> > * Day
> > * Hour
> > * Minute
> > * Second
> > * Milliseconds
> > 
> > This should get you going...
> > 
> > CChris
> 
> I've used your example to create a test of my own. When I extract the
> data, I get some mismatch in the time (dates seem to be correct).
> 
>   year  = peek(system_create_time +  0) + (peek(system_create_time +  1) *
>   256)
>   month = peek(system_create_time +  2) + (peek(system_create_time +  3) *
>   256)
>   dow   = peek(system_create_time +  4) + (peek(system_create_time +  5) *
>   256)
>   day   = peek(system_create_time +  6) + (peek(system_create_time +  7) *
>   256)
>   hour  = peek(system_create_time +  8) + (peek(system_create_time +  9) *
>   256)
>   min   = peek(system_create_time + 10) + (peek(system_create_time + 11) *
>   256)
>   sec   = peek(system_create_time + 12) + (peek(system_create_time + 13) *
>   256)
>   msec  = peek(system_create_time + 14) + (peek(system_create_time + 15) *
>   256)
> 
> (Same goes for system_last_access and system_last_write.)
> 
> * CREATED dates - all that is wrong is the hour - all other data is correct.
> Hour is
> one short, ie. instead of 16 (4 o'clock) it shows 15.
> 

Docs say hours are 0 thru 23, so that's expected.

> * ACCESSED dates - Date is correct, hours is one short, *and* minutes and
> seconds
> are both incorrect.
> 

Likewise for minutes and seconds, 0 thru 59.

Also, the day_of_week field starts with 0=sunday, 1=monday and so on. 
However, if I remember well, your reional ptions may alter this behaviour.

> * MODIFIED dates - Date is correct, hours is one short.
> 
> Can you figure out what I'm doing wrong?
> 
> PS! I know I might be doing it abit backwards, but I haven't been peeking and
> poking
> since back in those days of the Commodore 64. (I Couldn't find a peek that
> handled
> word size variables.) Also be aware that I shifted 
> 
> Kenneth aka ZNorQ

And no, Eu doesn't have a peek2() routine. What you did is correct.
You could make it faster by combining two 2-byte reads into one 4-byte read 
using peek4u though:

year  = peek(system_create_time +  0) + (peek(system_create_time +  1) * 256)
month = peek(system_create_time +  2) + (peek(system_create_time +  3) * 256)

could be replaced by:

atom temp
temp=peek4u(system_create_time)
year = remainder(temp,65536)
month= floor(temp/65536)

Btw, Sergio, that is exactly what my "orientation" was....

CChris