1. file properties with DIR function : Bug ?
Hello,
I'm trying the DIR function to use the date time modified value of each file.
I've found difference between two results :
with the MS explorer.
with the standard DIR function of Euphoria language.
the value of the second in the time property of the file is not the same
here, my code :
include file.e
sequence d
d = dir(current_dir())
pretty_print(1,d,{})
if getc(0) then
end if
here, the result for the last file :
{
{116't',101'e',115's',116't',95'_',100'd',105'i',114'r',46'.',101'e',
120'x',119'w'},
{97'a'},
99'c',
2006,
8,
14,
15,
43'+',
26
}
And the value of the modified date time property for the "test_dir.exw" file,
displaying by MS explorer on Window XP is : lundi 14 août 2006, 15 :43 : 24
the differenc is 2 seconds !
Anyone have an idea ? am I tired ? is it a bug ?
2. Re: file properties with DIR function : Bug ?
- Posted by Robert Craig <rds at RapidEuphoria.com>
Aug 14, 2006
-
Last edited Aug 15, 2006
chadal wrote:
> I'm trying the DIR function to use the date time modified value of each file.
>
> I've found difference between two results :
>
> with the MS explorer.
> with the standard DIR function of Euphoria language.
>
> the value of the second in the time property of the file is not the same
>
> here, my code :
>
> }}}
<eucode>
> include file.e
> sequence d
> d = dir(current_dir())
> pretty_print(1,d,{})
> if getc(0) then
> end if
> </eucode>
{{{
>
> here, the result for the last file :
> {
> {116't',101'e',115's',116't',95'_',100'd',105'i',114'r',46'.',101'e',
> 120'x',119'w'},
> {97'a'},
> 99'c',
> 2006,
> 8,
> 14,
> 15,
> 43'+',
> 26
> }
>
> And the value of the modified date time property for the "test_dir.exw" file,
>
> displaying by MS explorer on Window XP is : lundi 14 août 2006, 15 :43 : 24
>
> the differenc is 2 seconds !
>
> Anyone have an idea ? am I tired ? is it a bug ?
I checked a few files on my machine, and it looks ok. No difference.
The date stored on disk is only supposed to be accurate
to 2 seconds, so it's really an off-by-one error,
but I have no idea why you are seeing that.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
3. Re: file properties with DIR function : Bug ?
Hello Rob,
To be sure about my problem, i've wrote a small euphoria program using the
dir32 library from archives. I've used FileTimeToLocalFileTime and
FileTimeToSystemTime functions from kernel32.dll. the result confirms the
différenc between the euphoria DIR function and windows functions.
Is it an installation trouble ?
To understand what's happened, what kind of checks can i do ?
thank's for your answer.
4. Re: file properties with DIR function : Bug ?
chadal wrote:
> To be sure about my problem, i've wrote a small euphoria program using the
> dir32 library from archives. I've used FileTimeToLocalFileTime and
> FileTimeToSystemTime
> functions from kernel32.dll. the result confirms the différenc between the
> euphoria
> DIR function and windows functions.
> Is it an installation trouble ?
> To understand what's happened, what kind of checks can i do ?
I'm not sure what you mean by the "dir32" library, unless it's
Overman's dir232.zip (which I haven't looked at).
I support the standard dir() in Euphoria. I don't know why the
time stamp on a file could differ by 2 seconds in some cases.
I haven't noticed it on my machine using dir().
I simply retrieve a C structure, and have to multiply the "seconds"
field by 2, since for some reason Microsoft doesn't store the "seconds"
but rather the "seconds divided by two". Maybe it's a Y2K bug
Maybe in Europe Windows adjusted the clock at the turn
of the millennium? Maybe it depends on the version of Microsoft's
file system that you are using. I have no idea.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
5. Re: file properties with DIR function : Bug ?
On Mon, 21 Aug 2006 06:44:07 -0700, Robert Craig
<guest at RapidEuphoria.com> wrote:
>I simply retrieve a C structure, and have to multiply the "seconds"
>field by 2, since for some reason Microsoft doesn't store the "seconds"
>but rather the "seconds divided by two". Maybe it's a Y2K bug
That's odd. On my win98 box here, using kernel32 api, I just peek2u
the seconds and it is spot on. Try this:
-- dir() clone using windows api:
include dll.e
include machine.e
if platform()!=2 then ?9/0 end if --Win32 rqd (for kernel32!)
constant
-- FILETIME structure:
-- FTdwLowDateTime = 0, -- DWORD dwLowDateTime
-- FTdwHighDateTime = 4, -- DWORD dwHighDateTime
FTsize = 8,
-- WIN32_FIND_DATA structure:
FDwFileAttributes = 0, -- DWORD dwFileAttributes
-- FDtCreationTime = 4, -- FILETIME ftCreationTime
-- FDtLastAccessTime = 12, -- FILETIME ftLastAccessTime
FDtLastWriteTime = 20, -- FILETIME ftLastWriteTime
FDnFileSizeHigh = 28, -- DWORD nFileSizeHigh
FDnFileSizeLow = 32, -- DWORD nFileSizeLow
-- FDwReserved0 = 36, -- DWORD dwReserved0
-- FDwReserved1 = 40, -- DWORD dwReserved1
FDcFileName = 44, -- TCHAR cFileName[ MAX_PATH(=260)
]
-- FDcAltFileName = 304, -- TCHAR cAlternateFileName[ 14 ]
FDsize = 318,
-- SYSTEMTIME structure:
STwYear = 0, -- WORD wYear
STwMonth = 2, -- WORD wMonth
-- STwDayOfWeek = 4, -- WORD wDayOfWeek
STwDay = 6, -- WORD wDay
STwHour = 8, -- WORD wHour
STwMinute = 10, -- WORD wMinute
STwSecond = 12, -- WORD wSecond
-- STwMillisecs = 14, -- WORD wMilliseconds
STsize = 16,
INVALID_HANDLE_VALUE = -1,
kernel32 = open_dll("kernel32.dll"),
C_PTR = C_POINTER,
xFindFirstFile =
define_c_func(kernel32,"FindFirstFileA",{C_PTR,C_PTR},C_PTR),
xFindNextFile =
define_c_func(kernel32,"FindNextFileA",{C_PTR,C_PTR},C_INT),
xFindClose = define_c_proc(kernel32,"FindClose",{C_PTR}),
xFileTimeToLocalFileTime =
define_c_func(kernel32,"FileTimeToLocalFileTime",{C_PTR,C_PTR},C_INT),
xFileTimeToSystemTime =
define_c_func(kernel32,"FileTimeToSystemTime",{C_PTR,C_PTR},C_INT),
xFindData = allocate(FDsize),
xLocalFileTime = allocate(FTsize),
xSystemTime = allocate(STsize),
attrbits={#01,#02,#04,#00,#10,#20}, -- no volume_id
attrchar={'r','h','s','v','d','a'}
function peek_string(atom addr)
atom last
last = addr
while peek(last) do
last += 1
end while
if addr != last then
return peek( {addr, last - addr} )
else
return ""
end if
end function
function peek2u(atom addr)
return peek(addr) + peek(addr+1)*256
end function
function ConvertAttributes(integer c)
--
-- Convert the bitmap of file attributes into a text string
--
sequence res
res=""
for i=1 to length(attrbits) do
if and_bits(c,attrbits[i]) then
res&=attrchar[i]
end if
end for
return res
end function
global function apidir(sequence path)
integer d
atom lpPath, h
sequence res
while 1 do
--
-- Force consistent use of '\\' vs '/'.
--
d=find('/',path)
if d=0 then exit end if
path[d]='\\'
end while
if length(path) and path[length(path)]='\\' then
path&="*.*"
elsif not find('*',path) and not find('?',path) then
--
-- Check if the passed path is a directory
--
lpPath = allocate_string(path)
h = c_func(xFindFirstFile,{lpPath,xFindData})
if h != INVALID_HANDLE_VALUE then
if and_bits(peek(xFindData+FDwFileAttributes),#10) then
path &= "\\*.*"
end if
c_proc(xFindClose,{h})
end if
free(lpPath)
end if
lpPath = allocate_string(path)
h = c_func(xFindFirstFile,{lpPath,xFindData})
free(lpPath)
if h = INVALID_HANDLE_VALUE then return -1 end if
res={}
while 1 do
if
c_func(xFileTimeToLocalFileTime,{xFindData+FDtLastWriteTime,xLocalFileTime})
then end if
if c_func(xFileTimeToSystemTime,{xLocalFileTime,xSystemTime})
then end if
res=append(res,{peek_string(xFindData+FDcFileName),
ConvertAttributes(peek4u(xFindData+FDwFileAttributes)),
peek4s(xFindData+FDnFileSizeHigh)*#100000000+peek4u(xFindData+FDnFileSizeLow),
peek2u(xSystemTime+STwYear),
peek2u(xSystemTime+STwMonth),
peek2u(xSystemTime+STwDay),
peek2u(xSystemTime+STwHour),
peek2u(xSystemTime+STwMinute),
peek2u(xSystemTime+STwSecond)})
if not c_func(xFindNextFile,{h,xFindData}) then exit end if
end while
c_proc(xFindClose,{h})
return res
end function
include ppp.e -- or use pretty_print().
include file.e
pp(dir("C:\\*.bak"))
pp(apidir("C:\\*.bak"))
if getc(0) then end if
Regards,
Pete
6. Re: file properties with DIR function : Bug ?
Pete Lomax wrote:
> On Mon, 21 Aug 2006 06:44:07 -0700, Robert Craig
> <guest at RapidEuphoria.com> wrote:
>
>> I simply retrieve a C structure, and have to multiply the "seconds"
>> field by 2, since for some reason Microsoft doesn't store the "seconds"
>> but rather the "seconds divided by two". Maybe it's a Y2K bug
>
> That's odd. On my win98 box here, using kernel32 api, I just peek2u
> the seconds and it is spot on. Try this:
> }}}
<eucode>
> -- dir() clone using windows api:
> include dll.e
> include machine.e
>
> if platform()!=2 then ?9/0 end if --Win32 rqd (for kernel32!)
>
> constant
> -- FILETIME structure:
> -- FTdwLowDateTime = 0, -- DWORD dwLowDateTime
> -- FTdwHighDateTime = 4, -- DWORD dwHighDateTime
> FTsize = 8,
> -- WIN32_FIND_DATA structure:
> FDwFileAttributes = 0, -- DWORD dwFileAttributes
> -- FDtCreationTime = 4, -- FILETIME ftCreationTime
> -- FDtLastAccessTime = 12, -- FILETIME ftLastAccessTime
> FDtLastWriteTime = 20, -- FILETIME ftLastWriteTime
> FDnFileSizeHigh = 28, -- DWORD nFileSizeHigh
> FDnFileSizeLow = 32, -- DWORD nFileSizeLow
> -- FDwReserved0 = 36, -- DWORD dwReserved0
> -- FDwReserved1 = 40, -- DWORD dwReserved1
> FDcFileName = 44, -- TCHAR cFileName[ MAX_PATH(=260)
> ]
> -- FDcAltFileName = 304, -- TCHAR cAlternateFileName[ 14 ]
> FDsize = 318,
> -- SYSTEMTIME structure:
> STwYear = 0, -- WORD wYear
> STwMonth = 2, -- WORD wMonth
> -- STwDayOfWeek = 4, -- WORD wDayOfWeek
> STwDay = 6, -- WORD wDay
> STwHour = 8, -- WORD wHour
> STwMinute = 10, -- WORD wMinute
> STwSecond = 12, -- WORD wSecond
> -- STwMillisecs = 14, -- WORD wMilliseconds
> STsize = 16,
>
> INVALID_HANDLE_VALUE = -1,
>
> kernel32 = open_dll("kernel32.dll"),
> C_PTR = C_POINTER,
> xFindFirstFile =
> define_c_func(kernel32,"FindFirstFileA",{C_PTR,C_PTR},C_PTR),
> xFindNextFile =
> define_c_func(kernel32,"FindNextFileA",{C_PTR,C_PTR},C_INT),
> xFindClose = define_c_proc(kernel32,"FindClose",{C_PTR}),
> xFileTimeToLocalFileTime =
> define_c_func(kernel32,"FileTimeToLocalFileTime",{C_PTR,C_PTR},C_INT),
> xFileTimeToSystemTime =
> define_c_func(kernel32,"FileTimeToSystemTime",{C_PTR,C_PTR},C_INT),
>
> xFindData = allocate(FDsize),
> xLocalFileTime = allocate(FTsize),
> xSystemTime = allocate(STsize),
>
> attrbits={#01,#02,#04,#00,#10,#20}, -- no volume_id
> attrchar={'r','h','s','v','d','a'}
>
> function peek_string(atom addr)
> atom last
> last = addr
> while peek(last) do
> last += 1
> end while
> if addr != last then
> return peek( {addr, last - addr} )
> else
> return ""
> end if
> end function
>
> function peek2u(atom addr)
> return peek(addr) + peek(addr+1)*256
> end function
>
> function ConvertAttributes(integer c)
> --
> -- Convert the bitmap of file attributes into a text string
> --
> sequence res
> res=""
> for i=1 to length(attrbits) do
> if and_bits(c,attrbits[i]) then
> res&=attrchar[i]
> end if
> end for
> return res
> end function
>
> global function apidir(sequence path)
> integer d
> atom lpPath, h
> sequence res
> while 1 do
> --
> -- Force consistent use of '\\' vs '/'.
> --
> d=find('/',path)
> if d=0 then exit end if
> path[d]='\\'
> end while
> if length(path) and path[length(path)]='\\' then
> path&="*.*"
> elsif not find('*',path) and not find('?',path) then
> --
> -- Check if the passed path is a directory
> --
> lpPath = allocate_string(path)
> h = c_func(xFindFirstFile,{lpPath,xFindData})
> if h != INVALID_HANDLE_VALUE then
> if and_bits(peek(xFindData+FDwFileAttributes),#10) then
> path &= "\\*.*"
> end if
> c_proc(xFindClose,{h})
> end if
> free(lpPath)
> end if
> lpPath = allocate_string(path)
> h = c_func(xFindFirstFile,{lpPath,xFindData})
> free(lpPath)
> if h = INVALID_HANDLE_VALUE then return -1 end if
> res={}
> while 1 do
> if
> c_func(xFileTimeToLocalFileTime,{xFindData+FDtLastWriteTime,xLocalFileTime})
> then end if
> if c_func(xFileTimeToSystemTime,{xLocalFileTime,xSystemTime})
> then end if
> res=append(res,{peek_string(xFindData+FDcFileName),
>
> ConvertAttributes(peek4u(xFindData+FDwFileAttributes)),
>
> peek4s(xFindData+FDnFileSizeHigh)*#100000000+peek4u(xFindData+FDnFileSizeLow),
> peek2u(xSystemTime+STwYear),
> peek2u(xSystemTime+STwMonth),
> peek2u(xSystemTime+STwDay),
> peek2u(xSystemTime+STwHour),
> peek2u(xSystemTime+STwMinute),
> peek2u(xSystemTime+STwSecond)})
> if not c_func(xFindNextFile,{h,xFindData}) then exit end if
> end while
> c_proc(xFindClose,{h})
> return res
> end function
>
> include ppp.e -- or use pretty_print().
> include file.e
> pp(dir("C:\\*.bak"))
> pp(apidir("C:\\*.bak"))
> if getc(0) then end if
> </eucode>
{{{
The old DOS time format uses "seconds divided by two"
(I belive the purpose was to save storage space).
-- The following constants can also be used to refer
-- to elements of EUPHORIA's date() function:
constant
E_YEAR = 1, E_MONTH = 2, E_DAY = 3,
E_HOUR = 4, E_MINUTE = 5, E_SECOND = 6
global function dos_time (sequence t)
-- in : {year,month,day,hour,minute,second}
-- out: 32-bit integer in DOS time format
integer hiWord, loWord
hiWord = (t[E_YEAR]-1980)*#200 + t[E_MONTH]*#20 + t[E_DAY] -- date
loWord = t[E_HOUR]*#800 + t[E_MINUTE]*#20 + floor(t[E_SECOND]/2) -- time
return hiWord*#10000 + loWord
end function
Regards,
Juergen
--
Please excuse my flawed English. My native language is Euphoria.
7. Re: file properties with DIR function : Bug ?
On Mon, 21 Aug 2006 08:25:55 -0700, Juergen Luethje
<guest at RapidEuphoria.com> wrote:
>The old DOS time format uses "seconds divided by two"
>(I belive the purpose was to save storage space).
Ah, so exw's dir function uses int21h (or dos_interrupt) then, I
guess...
Regards,
Pete
8. Re: file properties with DIR function : Bug ?
Hello Pete,
thank for your answer. I've used your code and the two results show différent
values of the second property for a file.
Have you the same ? is it a "normal" différence between DOS ans windows XP ?
Cordialement,
François.
9. Re: file properties with DIR function : Bug ?
Hello Rob,
Sorry about my mistake. I've effectively used the Overman's dir232.zip library.
It is nearly like the Pete'code.
With Pete'code from its answer, do you obtain the same result on your machine or
like me, différences for second property ?
For some files, the différence is 1 second, and other, 2 seconds.
Cordialement,
François.
10. Re: file properties with DIR function : Bug ?
On Tue, 22 Aug 2006 08:20:21 -0700, chadal <guest at RapidEuphoria.com>
wrote:
>Hello Pete,
>
> thank for your answer. I've used your code and the two results show diff=
=E9rent values of the second property for a file.
>Have you the same ?
On win98, I get exactly the same values for the seconds from both
dir() and apidir(), every time. I don't have XP to test it on.
Regards,
Pete
11. Re: file properties with DIR function : Bug ?
chadal wrote:
> Sorry about my mistake. I've effectively used the Overman's dir232.zip
> library.
>
> It is nearly like the Pete'code.
>
> With Pete'code from its answer, do you obtain the same result on your machine
> or like me, différences for second property ?
> For some files, the différence is 1 second, and other, 2 seconds.
I tried Pete's code and checked about a dozen files.
They all showed the exact same time, including the seconds.
I used Windows XP, Service Pack 2, File System: FAT32.
I then tried my other, newer, XP machine.
The file system there is not FAT32, but rather NTFS.
On that machine I found files that differed by
one or two seconds. In fact it seemed to be a fairly
common occurrence.
So I'm guesing that maybe NTFS is storing the seconds
with more accuracy, but that accuracy is lost when a
conversion is made so dir() can read the information
using the old standard DOS format. The C code I'm using
for dir() is almost identical between DOS (using Watcom library calls)
and Windows (using the same Watcom library calls). For other
C compilers I use different code.
I don't have any immediate plans to "fix" this though.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
12. Re: file properties with DIR function : Bug ?
Hello Rob,
Thank you to have made the tests. I am reassured. I prefer that.
That confirms a concern with Windows and not a problem of defective installation
on my machine.
Cordialement,
FC
PostScriptum: All the discs of my machine are assembled NTFS
13. Re: file properties with DIR function : Bug ?
Hi there,
One thing i couldnt help but think about was if one system or
the other 'loses' or 'gains' one or two seconds around zero seconds.
Is it possible to create a file with time 0:58, 0:59, 0:01, or 0:02
seconds? ie is it a linear problem or non-linear?
If it's non-linear, there might be no way to create a file with
0:58 seconds as it's time, which would make me suspect of anything
but the file system (uless of course it was totally wacked).
On the other hand, if you can create files with times 0:58, 0:59,
0:00, 0:01, and 0:02 then i would think something is wrong with
the file system, barring of course that there is no other 'void'
in the time (ie not missing times of say 0:12 or any other either).
Take care,
Al
E boa sorte com sua programacao Euphoria!
My bumper sticker: "I brake for LED's"
From "Black Knight":
"I can live with losing the good fight,
but i can not live without fighting it".
"Well on second thought, maybe not."