Exiftool silently fails if path+filename too long

[tobwz]

I experienced an error when processing a file with a long path + filename.
Alltogether the length is 249 chars.

When I shorten the filename everything works.

I expected an error or warning from exiftool:

"path+filename too long (.... chars). File not processed."

Can this be added in the next release?

Thank you

[StarGeek]

This is a Windows specific problems and is something controlled by the Windows command line. Other command lines, such as on Mac/Linux, do not have this problem.

When I run a long file path (275 characters), exiftool gives me an error

Code Select Expand

Error: File not found - <longfilepath>

[obetz]

This is a Windows specific problems and is something controlled by the Windows command line.

I'd rather say this is a Perl problem, see https://exiftool.org/forum/index.php?topic=15095.0

Windows supports long path names, but many applications don't. Even the file manager shipped with Windows does not, but 3rd party file managers do.

[FrankB]

I may have a workaround. And that is the good old subst

Let's assume your complete folder name is shorter than 249 chars and so are your filenames. But together they are over 249 chars.

In cmd prompt:

Code Select Expand

cd "\very long directory name"
subst L: . (Where L: is an unused drive letter)
L:
exiftool <filenames>
To get rid of the L: drive

Code Select Expand

subst L: /d (Make sure you get out of the L: drive first)

[tobwz]

Yes, its most probably a Windows problem.

But exiftool could check in advance if this problem will happen for a certain file and inform the user with a warning.

Instead exiftool SILENTLY fails.

The "subst" trick works but is unhandy for everydays usage.
Should I really manually check every file for its length?
Or should I really apply the "subst" trick for every file I modify with exiftool?

No, the best solution would be if exiftool would do that AND WARN the user in these rare occasions.

[FrankB]

I just checked by creating a directory with 2 filenames. One file < 249 chars and one file > 249 chars (Including directory name)

Running this command in that directory:
exiftool -filename  "*.JPG"

Returns:
Error: File not found - ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789.jpg
======== abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghi.jpg
File Name                       : abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghi.jpg
    1 image files read
    1 files could not be read

So I would say the checks are there. Could you give a sample that does not work?

[obetz]

Yes, its most probably a Windows problem.

On which observations is this assumption based?

How could you rule out Perl as the cause?

Which file manager and tools are you using to create such long paths?

[FrankB]

I have been trying not to get involved in the question "Is it a Windows or a Perl problem?"

But after careful thoughts how to choose my words here it goes.
- It is a 'Windows Specific' problem. (It occurs on Windows and not on other systems)
- But that doesn't mean Windows doesn't support those filenames. The (only) problem is that the complete Windows API is not fully compatible, and probably never will, because that would break existing programs.
- Please also not that the filesystem used (Network, Fat32, ExFat, NTFS etc.) can make a difference.
- For an application to support those long filenames it must only use the API calls that support those long file names. For Perl it would mean to change Perl runtime.
- If they did, all Perl programs, not only Exiftool, could benefit from this.
- In the past I have made changes to ExifToolGui, so I'm aware of some of the changes one would have to make. Version V516 will give an error if you click on such a filename. The current Version V633 will show the file in the filelist and show a preview. But every attempt to read/write metadata using ExifTool will fail. https://github.com/FrankBijnen/ExifToolGui/issues/140

So I do agree with OBetz that Perl probably could be changed to solve it, but I also agree with Stargeek/Tobwz that it is a Windows specific problem.

But having said all that, these questions remain:
- Is the problem that no error message is shown, or do you want the files to be processed?
- What can we do with the current tools available to accomplish this?

[Phil Harvey]

The Windows file-handling routines used in ActivePerl have never been updated for the new wide-character support.  I presume the new file-handling routines would also handle long file names.  I have patched ExifTool multiple times to use the new routines in places, but these patches are messy and difficult to implement, and as a result ExifTool still uses the old file-handling routines in a number of places.

However, ExifTool should be issuing a warning if it can't open a file.  Can you give a specific example of the directory structure, file name, and command that would reproduce this effect?

- Phil

[obetz]

<rant> The real problem is that the Perl developers never liked Windows (to put it politely), and instead of solving the issues, they blame Windows.

That's often inappropriate: For example, Windows had long character support long before Linux, later they were blamed for using UTF-16 (UCS-2 in Windows NT 3.x) instead of UTF-8. Heck, it was the early nineties when they released it, so the decision for 16 bit was made even earlier. When did Perl start Unicode support? How good is Perl Unicode support today?

Python developers demonstrate how it can be made much better. Of course they also suffered from legacy Windows issues, but they have a constructive attitude, so they have solved most of the problems.

Perl seems to be backward-looking to me. </rant>

No, I'm not a youngster. I started programming (embedded) in the eighties.

[tobwz]

Just to clarify:

I am NOT using Perl.

I entered the command in Command Prompt (=Terminal) window in Windows.

My guess that Windows is the culprit is that there is a well know path+filename length limit of 255 chars.
Curiously the path+filename length in focus is only 249 chars.
maybe exiftool is using internally intermediate temp files which exceed the Windows max length.

Anyway: Exiftool should internally check the length and actively warn - if necessary - the user.

[obetz]

I am NOT using Perl.

ExifTool is a Perl program

My guess that Windows is the culprit is that there is a well know path+filename length limit of 255 chars.

Again my question: Which tools do you use to create and manage files with long path names?

If you do it with Windows tools, you seem to have set your system to support long paths. This disproves your assumption that Windows has a general problem with long paths.

[StarGeek]

I am NOT using Perl.

To clarify @obetz's comment, the Windows "executable" uses Perl's PAR packer module, which basically creates a zip type archive that contains the exiftool Perl script and a minimal Perl interpreter. When you run the "executable", these are extracted to the %TEMP% directory and then the Perl interpreter runs the exiftool Perl script from there.

If you open up your %TEMP% directory, you'll find a directory named "par-**********", with each * is a number or letter.  The exiftool program is in that directory.

[Somebody]

Hello, first a thanks for the good exiftool and greatings to all. It's shame that's from v12.88 no longer really portable is (x64 498 Files, 118 Folders, 32,0 MB vs 1F/10,4MB).

On my Systems Win7-10-11 i use exiftool 12.87 as 1File.exe in cmd with in PATH and have today the same Problem as the TF. I can use 248 chars including 2 quotes, so effectively 246 chars name length. Exiftool gives an error message, without indicating the length (see image). If it's known, it's not a problem. Perhaps it could be listed under "Known Problems".

Greatings Somebody

[obetz]

It's shame that's from v12.88 no longer really portable is (x64 498 Files, 118 Folders, 32,0 MB vs 1F/10,4MB).

"Portable" means that you can move it anywhere without "installation". That's still true.

The earlier "seemingly one file" ExifTool was even larger, because it extracted itself to %temp%, so it's 10MB where you store it plus 30MB (965 files) somewhere in %temp%. And if you installed a new version, the old temp files remained on your PC.