ExifTool Bug with long filenames/paths

Advanced Renamer forum
#1 : 21/06-21 20:21
James Matthew
James Matthew
Posts: 3

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:


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;


item.errorCode = 125;
item.errorMessage = 'File may receive wrong Exiftool data because a previous file\'s path is too long.';

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;

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!

21/06-21 20:21 - edited 21/06-21 20:25
#2 : 21/06-21 20:26
James Matthew
James Matthew
Posts: 3
Darn, it ate the extra spaces I used for formatting

21/06-21 20:26