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

[0Ethan0]

Hello,

I just wanted to report a bug about this script for future users and for the creator (thank you for making it available by the way ☺️).

The issue is if you have a file that starts with two dots, for example: C:\Temp\..test.bat

You will encounter an error with some, if not all, of the functions you use with this UDF.

I narrowed it down to the sub-function __LFN_Target_SetUnicodePrefix.
It searches for a string '\..' as a relative path but as you can see in the above case, it is a part of a filename.
And eventually ends up changing the filename and invalidating it - in the above case it will become: C:test.bat.

Just to point out that I learned now that most of the built in functions I use are already supported so this might not be relevant but in case anyone else is using it and if the author of the UDF wants to fix it I just thought it would be worth mentioning. Sadly even some of them have errors with long filenames, even though represented as they should work in the aforementioned link - for now, I ended up commenting out the relative element in the function above.

Thank you!

 

Edited July 1 by 0Ethan0

[orbs]

@0Ethan0 thank you for reporting this, and apologies for the late reply. i'll address this issue shortly.