If you prefix the file names with \\?\ Then you allow parsing of the extended length score and therefore avoid limiting the path length to 260 characters.
For this prefix to work, you need to call the Unicode versions of the Win32 API functions. Therefore, if you use Unicode Delphi, then this is all you need to do. But since you are using the preliminary Unicode Delphi, you will have to flip your own version of FindFirst , which calls the Unicode versions of the API functions. You will call FindFirstFileW , FindNextFileW , FindClose and use the Unicode version of the structure, WIN32_FIND_DATAW .
These issues are discussed in detail at MSDN: Naming Files, Paths, and Namespaces .
In your specific scenario, the documentation for FindFirstFileW causes the problem as follows:
In the ANSI version of this function, the name is limited to MAX_PATH characters. To extend this limit to 32,767 wide characters, call the Unicode function version and add "\? \" To the path.
Please note that the two file name fields in WIN32_FIND_DATAW limited to 260 characters. This is beautiful because they contain only the relative part of the name, that is, the name of the object relative to the containing directory. When calling FindFirstFileW you need to use the \\?\ Prefix.
To use the Unicode version of this API, you will use WideString for the lpFileName FindFirstFileW parameter and pass it using PWideChar(FileName) .
var FileName: WideString; ....
As for file attributes, they can be read from the WIN32_FIND_DATAW structure at each iteration. This part of your code should not change. The only thing you need to fix is ββto get parsing> 260 char on the initial call to FindFirstFileW . Everything else is proceeding quite normally.