WIN32_FIND_DATA (Structures)
Last changed: -62.91.108.152

.
Summary
TODO - a short description

C# Definition:

// The CharSet must match the CharSet of the
// corresponding PInvoke signature
[StructLayout(LayoutKind.Sequential, CharSet=CharSet.Auto)]
struct WIN32_FIND_DATA
{
   public uint dwFileAttributes;
   public long ftCreationTime;
   public System.Runtime.InteropServices.ComTypes.FILETIME ftLastAccessTime;
   public System.Runtime.InteropServices.ComTypes.FILETIME ftLastWriteTime;
   public uint nFileSizeHigh;
   public uint nFileSizeLow;
   public uint dwReserved0;
   public uint dwReserved1;
   [MarshalAs(UnmanagedType.ByValTStr, SizeConst=260)]
   public string cFileName;
   [MarshalAs(UnmanagedType.ByValTStr, SizeConst=14)]
   public string cAlternateFileName;
}

VB Definition:

    Structure WIN32_FIND_DATA
    Dim dwFileAttributes As Long
    Dim ftCreationTime As FILETIME
    Dim ftLastAccessTime As FILETIME
    Dim ftLastWriteTime As FILETIME
    Dim nFileSizeHigh As Long
    Dim nFileSizeLow As Long
    Dim dwReserved0 As Long
    Dim dwReserved1 As Long
    <MarshalAs(UnmanagedType.ByValTStr, SizeConst:=260)> _
      Dim cFileName As String
    <MarshalAs(UnmanagedType.ByValTStr, SizeConst:=14)> _
        Dim cAlternate As String
    End Structure

User-Defined Field Types:

None.

Notes:

I actually discovered a problem using the System.Runtime.InteropServices.ComTypes.FILETIME structure for the ftLastAccessTime and ftLastWriteTime members. The FILETIME is defined by the .NET framework as a high and low component, both of type int. This worked fine in almost all cases.

The problem I saw was when the file had no FILETIME information (0) as the file was created on a MAC inside of a ZIP file. When trying to get back to a DateTime using the DateTime.FromFileTimeUtc the DateTime created was 12/31/1979 23:52:50 (seven minutes and ten seconds before 1/1/1980) instead of 1/1/1980 00:00:00. I am in Arizona which always has a seven HOUR offset from GMT so I don't know if that played into the calculation or not (seven minutes vs. seven hours).

When I created my own structure and defined the components as UInt32 the problem disappeared. Here is the structure I used instead. A uint would also work instead of the UInt32, I have seen that used also.

    /// <summary>
    /// Structure used for Windows API calls related to file information.
    /// </summary>
    [StructLayout(LayoutKind.Sequential, CharSet = CharSet.Auto)]
    public struct WIN32_FIND_FILETIME
    {
    /// <summary>
    /// Specifies the low 32 bits of the FILETIME.
    /// </summary>
    public UInt32 dwLowDateTime;
    /// <summary>
    /// Specifies the high 32 bits of the FILETIME.
    /// </summary>
    public UInt32 dwHighDateTime;
    }

Documentation
FILETIME on MSDN

Neal Park

Documentation