Directory Date

[jmsrickland]

I can get file dates using the GetFileTime API but how do I get directrory dates

[fafalone]

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 Type FILETIME
  dwLowDateTime As Long
  dwHighDateTime As Long
End Type

Public Type WIN32_FILE_ATTRIBUTE_DATA
    dwFileAttributes As Long
    ftCreationTime As FILETIME
    ftLastAccessTime As FILETIME
    ftLastWriteTime As FILETIME
    nFileSizeHigh As Long
    nFileSizeLow As Long
End Type
Public Declare Function GetFileAttributesExW Lib "kernel32.dll" (ByVal lpFileName As Long, ByVal fInfoLevelId As Long, lpFileInformation As Any) As Long

Dim lpDir As String
lpDir = "C:\temp2"
Dim tAttr As WIN32_FILE_ATTRIBUTE_DATA
GetFileAttributesExW StrPtr(lpDir), 0&, tAttr

Then just convert the file times to dates...

Public Function FileTimeToDate(ft As FILETIME) As Date
Dim st As SYSTEMTIME
Dim ftl As FILETIME

Call FileTimeToLocalFileTime(ft, ftl)
Call FileTimeToSystemTime(ftl, st)

FileTimeToDate = SystemTimeToDate(st)
End Function
Public Function SystemTimeToDate(st As SYSTEMTIME) As Date
SystemTimeToDate = DateSerial(st.wYear, st.wMonth, st.wDay) + TimeSerial(st.wHour, st.wMinute, st.wSecond)
End Function

[Bonnie West]

If speed is not a concern, then a very easy way of obtaining the date stamps of a directory is by retrieving them via the DateCreated, DateLastModified and DateLastAccessed properties of the FileSystemObject's Folder object.

With CreateObject("Scripting.FileSystemObject").GetFolder("C:\Path\To\Folder")
    Debug.Print .DateCreated
    Debug.Print .DateLastModified
    Debug.Print .DateLastAccessed
End With

BTW, the GetFileTime function can also retrieve the date stamp of a directory.

[dilettante]

This works too:

Option Explicit

Private Shell As Object

Private Sub PrintItemDates(ByVal ItemName As String)
    Const ssfDESKTOP = 0

    Print "ItemName", ItemName
    With Shell.NameSpace(ssfDESKTOP).ParseName(ItemName)
        Print "ModifyDate", .ModifyDate
        Print "DateAccessed", .ExtendedProperty("System.DateAccessed")
        Print "DateCreated", .ExtendedProperty("System.DateCreated")
        Print "DateModified", .ExtendedProperty("System.DateModified")
    End With
End Sub

Private Sub Form_Load()
    Set Shell = CreateObject("Shell.Application")
    PrintItemDates App.Path
End Sub

Of course on sad and lonely, unsupported, unsafe, prehistoric versions of Windows (XP and earlier) only the first value will be displayed since the others return Null.

But the "plus" is that Shell is always loaded except in stripped down headless versions of Windows and this is a far lighter-weight solution than API calls or worse yet the FSO.

[Bonnie West]

... and this is a far lighter-weight solution than API calls or worse yet the FSO.

Doesn't appear to be true, as the following tests done with the aid of Process Hacker demonstrates:

Option Explicit

Private Sub Main()
    App.Title = "FSO"
    MsgBox "Before loading FSO...", vbInformation Or vbSystemModal
    MsgBox CreateObject("Scripting.FileSystemObject").GetFolder(App.Path).DateLastModified, vbInformation Or vbSystemModal
End Sub

Option Explicit

Private Sub Main()
    Const ssfDESKTOP = 0&

    App.Title = "Shell"
    MsgBox "Before loading Shell...", vbInformation Or vbSystemModal
    MsgBox CreateObject("Shell.Application").NameSpace(ssfDESKTOP).ParseName(App.Path).ExtendedProperty("System.DateModified"), vbInformation Or vbSystemModal
End Sub

Loaded Modules:

Before                                 |  After
---------------------------------------+---------------------------------------
FSO.exe           0x400000      16 kB  |  FSO.exe           0x400000      16 kB
advapi32.dll      0x77cf0000   640 kB  |  advapi32.dll      0x77cf0000   640 kB
apisetschema.dll  0x77da0000     4 kB  |  apisetschema.dll  0x77da0000     4 kB
                                       |  clbcatq.dll       0x76600000   524 kB
cryptbase.dll     0x75c30000    48 kB  |  cryptbase.dll     0x75c30000    48 kB
dwmapi.dll        0x74750000    76 kB  |  dwmapi.dll        0x74750000    76 kB
gdi32.dll         0x77ca0000   312 kB  |  gdi32.dll         0x77ca0000   312 kB
imm32.dll         0x765e0000   124 kB  |  imm32.dll         0x765e0000   124 kB
kernel32.dll      0x75fb0000   848 kB  |  kernel32.dll      0x75fb0000   848 kB
KernelBase.dll    0x75d50000   300 kB  |  KernelBase.dll    0x75d50000   300 kB
locale.nls        0x290000     412 kB  |  locale.nls        0x290000     412 kB
lpk.dll           0x76690000    40 kB  |  lpk.dll           0x76690000    40 kB
msctf.dll         0x776e0000   816 kB  |  msctf.dll         0x776e0000   816 kB
msvbvm60.dll      0x72940000  1.32 MB  |  msvbvm60.dll      0x72940000  1.32 MB
msvcrt.dll        0x76460000   688 kB  |  msvcrt.dll        0x76460000   688 kB
ntdll.dll         0x77b60000  1.23 MB  |  ntdll.dll         0x77b60000  1.23 MB
ole32.dll         0x774d0000  1.36 MB  |  ole32.dll         0x774d0000  1.36 MB
oleaut32.dll      0x767e0000   572 kB  |  oleaut32.dll      0x767e0000   572 kB
rpcrt4.dll        0x77630000   644 kB  |  rpcrt4.dll        0x77630000   644 kB
                                       |  scrrun.dll        0x17f0000     84 kB
                                       |  scrrun.dll        0x694c0000   168 kB
sechost.dll       0x77ae0000   100 kB  |  sechost.dll       0x77ae0000   100 kB
SortDefault.nls   0x1520000   2.81 MB  |  SortDefault.nls   0x1520000   2.81 MB
StaticCache.dat   0x1fc0000   9.19 MB  |  StaticCache.dat   0x1fc0000   9.19 MB
sxs.dll           0x75c40000   380 kB  |  sxs.dll           0x75c40000   380 kB
user32.dll        0x76510000   804 kB  |  user32.dll        0x76510000   804 kB
usp10.dll         0x777e0000   628 kB  |  usp10.dll         0x777e0000   628 kB
uxtheme.dll       0x74a70000   256 kB  |  uxtheme.dll       0x74a70000   256 kB
                                       |  version.dll       0x75290000    36 kB

Before                                 |  After
---------------------------------------+--------------------------------------------------------------------------------------
Shell.exe         0x400000      16 kB  |  Shell.exe         0x400000       16 kB
advapi32.dll      0x77cf0000   640 kB  |  advapi32.dll      0x77cf0000    640 kB
apisetschema.dll  0x77da0000     4 kB  |  apisetschema.dll  0x77da0000      4 kB
                                       |  cfgmgr32.dll      0x75dd0000    156 kB
                                       |  clbcatq.dll       0x76600000    524 kB
                                       |  comctl32.dll      0x74bd0000   1.62 MB
cryptbase.dll     0x75c30000    48 kB  |  cryptbase.dll     0x75c30000     48 kB
                                       |  cversions.2.db    0x520000       16 kB
                                       |  cversions.2.db    0x540000       16 kB
                                       |  devobj.dll        0x75d30000     72 kB
dwmapi.dll        0x74750000    76 kB  |  dwmapi.dll        0x74750000     76 kB
gdi32.dll         0x77ca0000   312 kB  |  gdi32.dll         0x77ca0000    312 kB
imm32.dll         0x765e0000   124 kB  |  imm32.dll         0x765e0000    124 kB
kernel32.dll      0x75fb0000   848 kB  |  kernel32.dll      0x75fb0000    848 kB
KernelBase.dll    0x75d50000   300 kB  |  KernelBase.dll    0x75d50000    300 kB
locale.nls        0x150000     412 kB  |  locale.nls        0x150000      412 kB
lpk.dll           0x76690000    40 kB  |  lpk.dll           0x76690000     40 kB
msctf.dll         0x776e0000   816 kB  |  msctf.dll         0x776e0000    816 kB
msvbvm60.dll      0x72940000  1.32 MB  |  msvbvm60.dll      0x72940000   1.32 MB
msvcrt.dll        0x76460000   688 kB  |  msvcrt.dll        0x76460000    688 kB
ntdll.dll         0x77b60000  1.23 MB  |  ntdll.dll         0x77b60000   1.23 MB
                                       |  ntmarta.dll       0x74280000    132 kB
ole32.dll         0x774d0000  1.36 MB  |  ole32.dll         0x774d0000   1.36 MB
oleaut32.dll      0x767e0000   572 kB  |  oleaut32.dll      0x767e0000    572 kB
                                       |  profapi.dll       0x75cb0000     44 kB
                                       |  propsys.dll       0x74ab0000    980 kB
rpcrt4.dll        0x77630000   644 kB  |  rpcrt4.dll        0x77630000    644 kB
sechost.dll       0x77ae0000   100 kB  |  sechost.dll       0x77ae0000    100 kB
                                       |  setupapi.dll      0x77900000   1.61 MB
                                       |  shell32.dll       0x240000       72 kB
                                       |  shell32.dll       0x76880000  12.29 MB
                                       |  shlwapi.dll       0x77b00000    348 kB
SortDefault.nls   0x1810000   2.81 MB  |  SortDefault.nls   0x1810000    2.81 MB
StaticCache.dat   0x20e0000   9.19 MB  |  StaticCache.dat   0x20e0000    9.19 MB
sxs.dll           0x75c40000   380 kB  |  sxs.dll           0x75c40000    380 kB
user32.dll        0x76510000   804 kB  |  user32.dll        0x76510000    804 kB
usp10.dll         0x777e0000   628 kB  |  usp10.dll         0x777e0000    628 kB
uxtheme.dll       0x74a70000   256 kB  |  uxtheme.dll       0x74a70000    256 kB
                                       |  Wldap32.dll       0x76090000    276 kB
                                       |  {6AF0698E-D558-4F6E-9B3C-3716689AF493}.2.ver0x0000000000000004.db  0x1270000  192 kB
                                       |  {AFBF9F1A-8EE8-4C77-AF34-C647E37CA0D9}.1.ver0x000000000000028f.db  0x1dd0000  908 kB
                                       |  {DDF571F2-BE98-426D-8288-1A9A39C3FDA2}.2.ver0x0000000000000001.db  0x12a0000  408 kB

[fafalone]

They both stink.

DLL functions calls 4ever!


And since we're apparently listing all the ways to do this; with oleexp3.tlb and its mPKEY module:

MsgBox GetPropertyKeyDisplayString("C:\Windows", PKEY_DateCreated)

Public Declare Function PSGetPropertyKeyFromName Lib "propsys.dll" (ByVal pszName As Long, ppropkey As PROPERTYKEY) As Long
Public Declare Function PSFormatPropertyValue Lib "propsys.dll" (ByVal pps As Long, ByVal ppd As Long, ByVal pdff As PROPDESC_FORMAT_FLAGS, ppszDisplay As Long) As Long
Public Declare Function SHGetPropertyStoreFromParsingName Lib "shell32" (ByVal pszPath As Long, pbc As Any, ByVal Flags As GETPROPERTYSTOREFLAGS, riid As UUID, ppv As Any) As Long
Public Declare Function PSGetPropertyDescription Lib "propsys.dll" (PropKey As PROPERTYKEY, riid As UUID, ppv As Any) As Long
Public Declare Function SysReAllocString Lib "oleaut32.dll" (ByVal pBSTR As Long, Optional ByVal pszStrPtr As Long) As Long
Public Declare Sub CoTaskMemFree Lib "ole32.dll" (ByVal PV As Long) ' Frees memory allocated by the shell
Public Function GetPropertyKeyDisplayString(szFile As String, pkProp As PROPERTYKEY) As String
Dim pps As IPropertyStore
Dim lpsz As Long
Dim ppd As IPropertyDescription

SHGetPropertyStoreFromParsingName StrPtr(szFile), ByVal 0&, GPS_DEFAULT, IID_IPropertyStore, pps
PSGetPropertyDescription pkProp, IID_IPropertyDescription, ppd
PSFormatPropertyValue ObjPtr(pps), ObjPtr(ppd), PDFF_DEFAULT, lpsz
SysReAllocString VarPtr(GetPropertyKeyDisplayString), lpsz
CoTaskMemFree lpsz
End Function

or without mPKEY:

MsgBox GetPropertyDisplayString("C:\Windows", "System.DateCreated")


Public Function GetPropertyDisplayString(szFile As String, szProp As String) As String
'Gets the string value of the given canonical property; e.g. System.Company, System.Rating, etc
'This would be the value displayed in Explorer if you added the column in details view
Dim pkProp As PROPERTYKEY
Dim pps As IPropertyStore
Dim lpsz As Long
Dim ppd As IPropertyDescription

PSGetPropertyKeyFromName StrPtr(szProp), pkProp
SHGetPropertyStoreFromParsingName StrPtr(szFile), ByVal 0&, GPS_DEFAULT, IID_IPropertyStore, pps
PSGetPropertyDescription pkProp, IID_IPropertyDescription, ppd
PSFormatPropertyValue ObjPtr(pps), ObjPtr(ppd), PDFF_DEFAULT, lpsz
SysReAllocString VarPtr(GetPropertyDisplayString), lpsz
CoTaskMemFree lpsz


End Function

[Bonnie West]

They both stink.

DLL functions calls 4ever!

Still, nothing beats the brevity, readability and elegance of the FSO.


Different methods usually have different strengths and weaknesses and knowing when it is best to use one over the other is, IMO, one of the traits of an effective programmer.

[AngelV]

Duplicate - forum site slow

[AngelV]

duplicate

[AngelV]

They both stink.

DLL functions calls 4ever!


And since we're apparently listing all the ways to do this; with oleexp3.tlb and its mPKEY module:

MsgBox GetPropertyKeyDisplayString("C:\Windows", PKEY_DateCreated)

Public Declare Function PSGetPropertyKeyFromName Lib "propsys.dll" (ByVal pszName As Long, ppropkey As PROPERTYKEY) As Long
Public Declare Function PSFormatPropertyValue Lib "propsys.dll" (ByVal pps As Long, ByVal ppd As Long, ByVal pdff As PROPDESC_FORMAT_FLAGS, ppszDisplay As Long) As Long
Public Declare Function SHGetPropertyStoreFromParsingName Lib "shell32" (ByVal pszPath As Long, pbc As Any, ByVal Flags As GETPROPERTYSTOREFLAGS, riid As UUID, ppv As Any) As Long
Public Declare Function PSGetPropertyDescription Lib "propsys.dll" (PropKey As PROPERTYKEY, riid As UUID, ppv As Any) As Long
Public Declare Function SysReAllocString Lib "oleaut32.dll" (ByVal pBSTR As Long, Optional ByVal pszStrPtr As Long) As Long
Public Declare Sub CoTaskMemFree Lib "ole32.dll" (ByVal PV As Long) ' Frees memory allocated by the shell
Public Function GetPropertyKeyDisplayString(szFile As String, pkProp As PROPERTYKEY) As String
Dim pps As IPropertyStore
Dim lpsz As Long
Dim ppd As IPropertyDescription

SHGetPropertyStoreFromParsingName StrPtr(szFile), ByVal 0&, GPS_DEFAULT, IID_IPropertyStore, pps
PSGetPropertyDescription pkProp, IID_IPropertyDescription, ppd
PSFormatPropertyValue ObjPtr(pps), ObjPtr(ppd), PDFF_DEFAULT, lpsz
SysReAllocString VarPtr(GetPropertyKeyDisplayString), lpsz
CoTaskMemFree lpsz
End Function

or without mPKEY:

MsgBox GetPropertyDisplayString("C:\Windows", "System.DateCreated")


Public Function GetPropertyDisplayString(szFile As String, szProp As String) As String
'Gets the string value of the given canonical property; e.g. System.Company, System.Rating, etc
'This would be the value displayed in Explorer if you added the column in details view
Dim pkProp As PROPERTYKEY
Dim pps As IPropertyStore
Dim lpsz As Long
Dim ppd As IPropertyDescription

PSGetPropertyKeyFromName StrPtr(szProp), pkProp
SHGetPropertyStoreFromParsingName StrPtr(szFile), ByVal 0&, GPS_DEFAULT, IID_IPropertyStore, pps
PSGetPropertyDescription pkProp, IID_IPropertyDescription, ppd
PSFormatPropertyValue ObjPtr(pps), ObjPtr(ppd), PDFF_DEFAULT, lpsz
SysReAllocString VarPtr(GetPropertyDisplayString), lpsz
CoTaskMemFree lpsz


End Function

Hi fafalone,

Been using this but i get extra 0x3f character (? question mark character) when passing System.DateCreated as mPKEY
?20/?02/?2024 ??10:45

BTW, the vbforums site is very slow today and doesn't refresh most of the time.

[fafalone]

Are you sure they're 0x3f? That should only the the result of after putting it into an ANSI textbox where VB replaces Unicode characters with ?s.

They should be Unicode control characters 0x200E and 0x200F, control characters for left-to-right.

For display compatible with ANSI, I filter the most common ones:

            GetPropertyKeyDisplayString = Replace$(GetPropertyKeyDisplayString, ChrW$(&H200E), "")
            GetPropertyKeyDisplayString = Replace$(GetPropertyKeyDisplayString, ChrW$(&H200F), "")
            GetPropertyKeyDisplayString = Replace$(GetPropertyKeyDisplayString, ChrW$(&H202A), "")
            GetPropertyKeyDisplayString = Replace$(GetPropertyKeyDisplayString, ChrW$(&H202C), "")

[jj2007]

I like it shorter:

If_ Exist("\VB6\VB6.EXE") Then PrintLine "Last modified ", GfDate$(-1), ", ", GfTime$(-1)

Output: Last modified 25.06.1998, 01:00:00

That takes 50 microseconds and uses FindFirstFileExW. Seriously, you are worried about speed? When was the last time you needed to know a folder date in an innermost loop with a Million iterations?

[fafalone]

I had to be concerned about speed while making my shell browser control. It was unacceptable the folders with 10000+ items were taking 30+ seconds to load.

So I write a high performance loader based around NtQueryDirectoryFile. It makes a huge difference when System32, for instance, loads in 2-3s instead of 15-20s.

[SmUX2k]

That takes 50 microseconds and uses FindFirstFileExW. Seriously, you are worried about speed? When was the last time you needed to know a folder date in an innermost loop with a Million iterations?

I recently wrote a bit of code that takes a starting folder and iterates through the folders and files within to find out what files are available (for my stock data app...all the tick data is stored in ZIPs, and there's 4000+ folders with the ZIPs inside) and then goes into those ZIPs to find out what files are within those ZIPs. It isn't getting a folder date like the above request, but even with the working with ZIP files it outputs a list of ~50k files in a matter of minutes. Speed is important when processing large amounts of data from large amounts of files, and had that taken 30 minutes or more I wouldn't have been happy with it at all.

Backup software would be a good example of needing the date/time of a file or folder quickly, as it will use the dates to decide whether or not to create a backup of a specific file based on whether it thinks the file in question has been written to since the last time a backup was done. On a hard drive with millions of files, that would need to be done fairly quickly. Sync software (essentially the same thing) would use the same processes, though usually on a smaller scale.

Regardless of how many times a process needs to be run, shaving milliseconds off its run-time will add up over all the different processes that run slightly faster, and an app that takes 10 minutes to do its processing could easily run in half the time or less if enough care and attention is put towards efficient consideration of the speeds of the processes being created. We should always be mindful of the speed differences between different options, and use the quickest option if it doesn't have massive overheads that are otherwise detrimental.

Optimising code is usually the next step I take after finishing a bit of code, and I will try to find ways to reduce bottlenecks and improve the speed at which it processes...often I will implement the faster methods in the first (creation) step, but not always...doesn't take long to read through code and look at where there might be bottlenecks slowing things down.

[AngelV]

@fafalone

Thanks.

I was actually displaying the text in the debug window and on a standard MsgBox which are ansi.

Why would PSFormatPropertyValue return a string with such invisible characters only when retrieving date and time property values?!

I got the 0x3f when placing the string in a byte array using StrConv and checking each character

[fafalone]

I've definitely encountered them in other properties-- the 0x202A/C controls aren't part of dates, I forget which ones I added them for.

Perhaps it's related to whether a type is natively a string or not? Dates aren't, but name and filetype would be.

[AngelV]

I've definitely encountered them in other properties-- the 0x202A/C controls aren't part of dates, I forget which ones I added them for.

Perhaps it's related to whether a type is natively a string or not? Dates aren't, but name and filetype would be.

Thanks fafalone. I have learnt so much from your work on interfaces.

[jj2007]

I had to be concerned about speed while making my shell browser control. It was unacceptable the folders with 10000+ items were taking 30+ seconds to load.

So I write a high performance loader based around NtQueryDirectoryFile. It makes a huge difference when System32, for instance, loads in 2-3s instead of 15-20s.

FindFirstFileEx is a thin wrapper for NtQueryDirectoryFile. There is a little extra overhead, of course, but most of it would also be needed for a direct call to NtQueryDirectoryFile, such as NtOpenFile (not sure about RtlReleaseRelativeName and RtlFree, though).

it outputs a list of ~50k files in a matter of minutes.

AMD Athlon Gold 3150U with 256GB SSD, using FindFirstFileExW:

59 s for 326323 C:\Windows files
38 s for 326323 C:\Windows files
38 s for 326323 C:\Windows files
38 s for 326323 C:\Windows files
38 s for 326323 C:\Windows files

The first call is slow, then the disk cache kicks in; apparently it's still faster than non-cached reads from the SDD.

[fafalone]

The little extra overhead can add up. We had compared them directly at some point IIRC.

[jj2007]

The little extra overhead can add up. We had compared them directly at some point IIRC.

Here is the 2015 VB6 thread, and here is the original 2011 source

[SmUX2k]

FindFirstFileEx is a thin wrapper for NtQueryDirectoryFile. There is a little extra overhead, of course, but most of it would also be needed for a direct call to NtQueryDirectoryFile, such as NtOpenFile (not sure about RtlReleaseRelativeName and RtlFree, though).

AMD Athlon Gold 3150U with 256GB SSD, using FindFirstFileExW:

59 s for 326323 C:\Windows files
38 s for 326323 C:\Windows files
38 s for 326323 C:\Windows files
38 s for 326323 C:\Windows files
38 s for 326323 C:\Windows files

The first call is slow, then the disk cache kicks in; apparently it's still faster than non-cached reads from the SDD.

I notice in my post you are very particular about where you quote me. Had you actually quoted the ENTIRE line of what I said (as it was iterating through 50k files in minutes INCLUDING checking in ZIP files) then your comparison comment would have been moot as yours doesn't interact with ZIP files.

[jj2007]

I notice in my post you are very particular about where you quote me. Had you actually quoted the ENTIRE line of what I said (as it was iterating through 50k files in minutes INCLUDING checking in ZIP files) then your comparison comment would have been moot as yours doesn't interact with ZIP files.

Valid point, SmUX2k. However, extracting names from ZIP files has little to do with FindFirstFileEx performance.

335 ms for getting 19388 filenames from 117 zipfiles

(I don't have enough ZIP files for extracting 50k filenames)