LFN UDF - overcome MAX_PATH limit of 256 chars

[orbs]

16 hours ago, Deye said:

will a generated array from _FileListToArrayRec, have a problem holding an exceeding MAX_PATH ?

@Deye

yes, _FileListToArrayRec does (or should; i tested quite some time ago) return paths longer than MAX_PATH. i know this because i once wrote a utility to discover too long paths, and at one instance of it i did use _FileListToArrayRec. eventually i used recursion to scan the file system, without using the unicode prefix at all. this is because in general, reading metadata for long file names is feasible. the issue becomes apparent when you need to perform some action on those files.

 

[Mbee]

Hey, @orbs, your UDF is truly marvelous!  Thank you!

I have a question, though, if you don't mind: Are files created/renamed (etc) using your UDF compatible with Windows Explorer? For example, if I use your UDF to rename a file such that the new total filename and path length exceeds MAX_PATH, can Windows Explorer still deal with it?

Ordinarily, I would think not, but since the UDF creates unicode file/path names, it seems to me that it might be possible.

Sorry if this is a stupid question!

 

[orbs]

@Mbee,

you should have no problem listing or viewing files managed by this UDF in Windows Explorer. but if you try to operate on them - e.g. move them, delete them etc. - you may encounter the same issue this UDF came to resolve in the first place.

[Mbee]

Thanks for your reply.  You have clearly written a master-level UDF, and I thank and congratulate you!

 

[orbs]

script converter updates: (updated in first post - v1.4.0.3)

main include folder was not properly assigned (this was not detected until now as it's very rare to put a custom UDF there. sorry).

as of AutoIt v3.3.14.0 (actually, v3.3.13.1) FileFindNextFile supports returning an attributes string (similar to the string returned by FileGetAttrib) in the @extended macro. a UDF cannot mimic this behaviour because SetExtended & SetError can assign only integer values to @extended. fortunately - in this particular case - this is not an issue, since FileFindNextFile accepts a handle as a parameter, not a file name; hence it does not require any LFN-related modification. it was treated as an LFN function simply for me to avoid handling an exception.

so, to keep the new functionality, and not cripple LFN compatibility, it is advised to not convert FileFindNextFile to _LFN_FileFindNextFile. the updated script converter is now configured accordingly by default. if you do wish to convert FileFindNextFile to _LFN_FileFindNextFile, you can set it in the "Preferences" menu.

Edited November 29, 2016 by orbs