open efu file with notepad,
there is:
Filename,Size,Date Modified,Date Created,Attributes
"E:\Pink Floyd others\Tourbooks And Programmes\1994-09-07 - Praha Programme\pinkfloydprogramcz.jpg",99804,129981824854218750,129981602870625000,32
99804:means size
129981824854218750 means Date Modified
129981602870625000 means Date Created
32:means ?
question:
why 129981824854218750 means Date Modified
why 129981602870625000 means Date Created
and what is 32 means?
thank you void
what is this mean in efu
Re: what is this mean in efu
what tools or softwave can turn 129981824854218750 to 2012-11-24 06:14 or turn 2012-11-24 06:14 to 129981824854218750
thanks void
Re: what is this mean in efu
To roughly convert to the date/time with Excel:
If you can work out how to split the 64bit integer into the low and high DWORDs this would work perfectly.
There are probably apps out there that can do this better. Excel 2013 x64 should be fine if you use BITAND.
The reason for not using a readable date format was to keep the accuracy at 100 nanoseconds.
- From the Data menu, from Import External Data, click Import Data...
- Change files of types to *.csv.
- Open your efu file list.
- Click Next.
- Check Comma.
- Click Next.
- Change each column to text.
- Click Finish.
- Open the Visual Basic Editor with Alt + F11.
- Create a new module:
Code: Select all
Public Declare Function SystemTimeToFileTime Lib "kernel32" (lpSystemTime As SYSTEMTIME, lpFileTime As FILETIME) As Long Public Declare Function FileTimeToLocalFileTime Lib "kernel32" (lpFileTime As FILETIME, lpLocalFileTime As FILETIME) As Long Public Declare Function FileTimeToSystemTime Lib "kernel32" (lpFileTime As FILETIME, lpSystemTime As SYSTEMTIME) As Long Public Type FILETIME dwLowDateTime As Long dwHighDateTime As Long End Type Public Type SYSTEMTIME wYear As Integer wMonth As Integer wDayOfWeek As Integer wDay As Integer wHour As Integer wMinute As Integer wSecond As Integer wMilliseconds As Integer End Type Public Function LocalTimeToUTC(Value As String) As Date Dim st As SYSTEMTIME Dim ft As FILETIME Dim localft As FILETIME ft.dwHighDateTime = Application.Evaluate(Value & "/4294967296") ft.dwLowDateTime = 0 Call FileTimeToLocalFileTime(ft, localft) Call FileTimeToSystemTime(localft, dteSystemTime) LocalTimeToUTC = CDate(Format(st.wDay & "/" & st.wMonth & "/" & st.wYear & " " & st.wHour & ":" & st.wMinute, "dd/mm/yy hh:mm")) End Function
- In a new cell, enter the following command:
Code: Select all
=localtimetoutc(D2)
- Where D2 is a FILETIME cell.
If you can work out how to split the 64bit integer into the low and high DWORDs this would work perfectly.
There are probably apps out there that can do this better. Excel 2013 x64 should be fine if you use BITAND.
The reason for not using a readable date format was to keep the accuracy at 100 nanoseconds.
Re: what is this mean in efu
Function EFU_to_MS_serial(efu_time As Double, utc_correction As Double) As Double
'
' Excel VBA function:
'
' Converts EFU date-time values from VoidTools utility program *Everything* export of file lists to Microsoft serial dates.
' (Import them as floating point values rather than integers or strings, or convert in the function call with *1 multiplication).
'
' Background: The conversion function offered on the Voidtool forum (circa 2014) is incorrect (and has a typo so I doubt whether is
' was ever compiled. And it is much too complicated.)
'
' EFU file times are in 100 ns counts from a base time of 1-Jan-1601
' MS serial times are an integer number of days + fractional part of a day since a base time of 1-00-1900.
'
' The main thing is to correct for the difference in base times.
'
' Since Excel and VBA cannot perform date arithmetic before their base time I did a future based compuation:
' Since 1900-1601 = 299 years, there should be approximately 299 x 365.2422699 = 109207.44 days after this
' (fictional) '0' base MS date, as well as before. Comparing a conversion with this Base_Time_Offset to an
' actual Microsoft file time reveals (vs an Everything exported file list) that the actual offset here should be
' 109205 days. This then needs to be converted to EFU units of 100ns.
'
' See: https://en.wikipedia.org/wiki/Sidereal_time
'
' But then the times are 'off' by exactly four hours. This is easily explained as the difference between UTC time and my East
' coast location: a 4.00 hour correction, including for now DST. Remember 4/24 of a day!
'
' NOTE: I made the utc_correction a positive number and a subtraction in the implementation. More properly it is a negative
' correction as UTC is always larger. Feel free to change, but document what you do.
'
' TEST: I exported 100 mpg files from Everything and compared their modified times converted with this fuctions with what
' Windows File Explorer reports. Deltas were 00:00.0 to 00:01.0 seconds, Everything values were always slightly larger.
' Average was 0.5 second. This is close enough for my needs. I could not tell if the lowest order binary digits of the EFU
' values contained the UTC embedded corrections or not.
'
' Feel free to modify this function to try for automatic, location based utc correction but note that the correction should be
' based on the utc in effect at the relevant file time, not the current system time. Modified, created, accessed could all
' be vastly different. I have run into this misapplication issue with other programs.
'
Const ns100_per_day = 864000000000# ' 86400 sec x 1.0e7 units of 100 ns per second
Const Base_Time_Offset = 109205# * ns100_per_day ' approx delta betw EFU and MS serial base times = 299 yrs x 365.2422699 dy/yr x 8.64e11 100ns/dy
EFU_to_MS_serial = (efu_time - Base_Time_Offset) / ns100_per_day - utc_correction
End Function
'
' Excel VBA function:
'
' Converts EFU date-time values from VoidTools utility program *Everything* export of file lists to Microsoft serial dates.
' (Import them as floating point values rather than integers or strings, or convert in the function call with *1 multiplication).
'
' Background: The conversion function offered on the Voidtool forum (circa 2014) is incorrect (and has a typo so I doubt whether is
' was ever compiled. And it is much too complicated.)
'
' EFU file times are in 100 ns counts from a base time of 1-Jan-1601
' MS serial times are an integer number of days + fractional part of a day since a base time of 1-00-1900.
'
' The main thing is to correct for the difference in base times.
'
' Since Excel and VBA cannot perform date arithmetic before their base time I did a future based compuation:
' Since 1900-1601 = 299 years, there should be approximately 299 x 365.2422699 = 109207.44 days after this
' (fictional) '0' base MS date, as well as before. Comparing a conversion with this Base_Time_Offset to an
' actual Microsoft file time reveals (vs an Everything exported file list) that the actual offset here should be
' 109205 days. This then needs to be converted to EFU units of 100ns.
'
' See: https://en.wikipedia.org/wiki/Sidereal_time
'
' But then the times are 'off' by exactly four hours. This is easily explained as the difference between UTC time and my East
' coast location: a 4.00 hour correction, including for now DST. Remember 4/24 of a day!
'
' NOTE: I made the utc_correction a positive number and a subtraction in the implementation. More properly it is a negative
' correction as UTC is always larger. Feel free to change, but document what you do.
'
' TEST: I exported 100 mpg files from Everything and compared their modified times converted with this fuctions with what
' Windows File Explorer reports. Deltas were 00:00.0 to 00:01.0 seconds, Everything values were always slightly larger.
' Average was 0.5 second. This is close enough for my needs. I could not tell if the lowest order binary digits of the EFU
' values contained the UTC embedded corrections or not.
'
' Feel free to modify this function to try for automatic, location based utc correction but note that the correction should be
' based on the utc in effect at the relevant file time, not the current system time. Modified, created, accessed could all
' be vastly different. I have run into this misapplication issue with other programs.
'
Const ns100_per_day = 864000000000# ' 86400 sec x 1.0e7 units of 100 ns per second
Const Base_Time_Offset = 109205# * ns100_per_day ' approx delta betw EFU and MS serial base times = 299 yrs x 365.2422699 dy/yr x 8.64e11 100ns/dy
EFU_to_MS_serial = (efu_time - Base_Time_Offset) / ns100_per_day - utc_correction
End Function
Re: what is this mean in efu
Microsoft uses this format (129981824854218750) also for their DS* utilities (dsget, dsquery, ...) to query/change Active Directory.
Their advice was (years ago) to use this formula in Excel to convert it to a "human" date:
(Assuming the date is in cell A1)
That is about the same formula like you used
Format the cell containing this formula as a date and you're done.
Minus Daylight Saving Time offset that is. But as I used it for things like last logon date, that wasn't a real problem.
In CMD scripts I used:
(which had to be parsed further to get a ISO86something date).
Note how w32time also reports the nanoseconds resolution.
Note2: Thanks to Everything it took me just seconds to find this again, hidden in a dusty corner of the harddisk. Nice!
PowerShell:
Results in:
vrijdag 23 november 2012 23:14:45
(Dutch local time)
Their advice was (years ago) to use this formula in Excel to convert it to a "human" date:
Code: Select all
= A1 / ( 8,64 * 100000000000 ) - 109205
That is about the same formula like you used
Format the cell containing this formula as a date and you're done.
Minus Daylight Saving Time offset that is. But as I used it for things like last logon date, that wasn't a real problem.
In CMD scripts I used:
Code: Select all
set LDIFDE=129981824854218750
for /f "usebackq tokens=1* delims=-" %%x in (`w32tm.exe /ntte %LDIFDE%`) do set THISTIME=%%y
Note how w32time also reports the nanoseconds resolution.
Note2: Thanks to Everything it took me just seconds to find this again, hidden in a dusty corner of the harddisk. Nice!
PowerShell:
Code: Select all
[datetime]::FromFileTime(129981824854218750)
vrijdag 23 november 2012 23:14:45
(Dutch local time)