ExifTool Bug with long filenames/paths

Hello!

I found a bug when working with overly long paths and scripts or exiftool tags.

Since I have long path support enabled, which means I can create filenames and paths greater than the 260 character limit. ExifTool can't work with such paths and usually throws a missing file error (it doesn't support \\?\ either as far as I know).
However, if one such a file is in a filelist and a rename operation uses exiftool tags like <ExifTool:Title>, a critical bug occurs when renaming:
Instead of receiving an errorCode of 125 (found that by luck, an update to https://www.advancedrenamer.com/doc/errorcodes.p hp would be cool!), the rename operation seemingly succeeds but with empty Strings for all tags used.

Id est, if I use a rename like "<ExifTool:Artist> - <ExifTool:Title>" on the name, this results in " - .m4a" as new filename.
The critical bug is however, that such files sometimes confuse their name and the renaming of the following files:
Given the scheme above, the problematic file then assumes the tag data of the following file and every file after it as well.
riders on the storm.m4a -> "The Doors - Riders on the Storm.m4a"
Some really long title[...].m4a -> "twentyonepilots - Jumpsuit.m4a"
Jumpsuit.m4a -> "The Stranglers - Golden Brown.m4a"
Golden Brown.m4a -> " - .m4a"

I can reproduce the issue, but sometimes I just get unexpected behaviour. For example, I once had the problem mentioned above, but seemingly random after about three tag-shifted files it displayed ExifTool Error for the rest.
With more too-long files, the tags were shifted by the number of too-long files.

These files can't be added by dragging them onto the list, but dragging a folder containing them adds them.

I wrote a simple script to prevent the issue above where other files are dragged in and that the empty strign rename stays unnoticed:


Pre:

var atLeastOnePathTooLong = false;

function byteLength(str) {
var s = str.length;
for (var i=str.length-1; i>=0; i--) {
var code = str.charCodeAt(i);
if (code > 0x7f && code <= 0x7ff) s++;
else if (code > 0x7ff && code <= 0xffff) s+=2;
if (code >= 0xDC00 && code <= 0xDFFF) i--; //trail surrogate
}
return s;
}

Script:

if(atLeastOnePathTooLong){
item.errorCode = 125;
item.errorMessage = 'File may receive wrong Exiftool data because a previous file\'s path is too long.';
return;
}

var l = byteLength(item.filename)

if(l > 259){
item.errorCode = 125;
item.errorMessage = 'Path has byte length of ' + l + ', exiftool wont find file.';
atLeastOnePathTooLong = true;
return;
}


When writing the script I also found that the files were messing with the debugger. Any log()s in other scripts before the one I posted are not shown at all, and log()s in scripts afterwards seem to overwrite if I add a log on top of the script above.

I saw the other post about MAX_PATH and that a new version is coming out soon - maybe the bad renaming will already fixed by that!
I guess since exiftool doesn't seem to support long paths itself, the best that can be done is to warn if a file can't be processed by exiftool and that no other files with ok paths are affected. If there's a way to get it fully working with long paths that would of course be even better!

---

Darn, it ate the extra spaces I used for formatting

---