New API WindowsLongPath option

[FrankB]

Hi Phil,

I'm wondering why you tested for $path =~ /\\\\/ rather than $path =~ /^\\\\/.  Can the "\\" appear in the middle of the path too?

That is because I'm not familiar with regex'es. I try to stay away from them. 
The test should be as you suggest '$path =~ /^\\\\/.'.
'\\' could be in the middle, but that should not be considered.

but not "\\?\"

True. I assume that prepending has already been done then.

If I understand, it looks like the first "\" must be removed and "\\?\UNC" must be added.

That was easiest for me to do given the existing code. To put it in 'human' words:

Only if it is a UNC path (no matter if it is relative or absolute) the result should be: \\?\UNC\server\share\rest of the path.

Examples:

1. Absolute path (Path starts with \\, CWD doesn't matter)
Path: \\10.10.10.12\foto\longdir1\abcd.jpg
result: \\?\UNC\10.10.10.12\foto\longdir1\abcd.jpg

2. Relative path. (Path does not start with \\, CWD starts with \\)
CWD: \\10.10.10.12\foto\longdir1
Path: abcd.jpg, or .\abcd.jpg (..\ not easy to test for me)
result: \\?\UNC\10.10.10.12\foto\longdir1\abcd.jpg

If you have thoughts why all this is needed, dont blame me. I'm only the messenger. I'm just repeating what's on the Microsoft learn page

Really appreciate your Open-Mindedness

Frank
 

[FrankB]

One more remark, about mitigation.

With -Api WindowsLongPath=1 you always prepend '\\?\', or '\\?\UNC\'. You could have opted to only do that if the resulting complete path exceeds 260 chars. Both methods have their advantage:

Only when length>260: Less chance that this change affects existing use(users)
Always: Any errors will show up right away. (I'm not native English, but I think the phrase 'No guts, no glory' applies here)

To be honoust, I wouldn't know what to choose.

Frank

[Phil Harvey]

Thanks Frank.  Your input has been very helpful.  I'll continue testing at my end because I still think I could be missing something.

- Phil

[Phil Harvey]

I found 2 cases that need patching:

1. If an absolute path on the current drive is specified.  (ie. path starts with a single "\")

2. If a relative path on a different drive is specified.  (ie. path starts with "d:relpath" without a "/" before relpath)

I'll fix these.

- Phil

[FrankB]

I agree.

I'll be glad to test it, if you have something. You dont need to release a complete version, I can merge the differences.

Frank

[Phil Harvey]

Thanks Frank.

I've patched these 2 cases and also handled the case where relative directories ("." or "..") appear in fully qualified directory names.  Of course, this necessitated a major rewrite.  Attached is my current version of ExifTool.pm

I've also added an API Debug option to give you some debugging output.

I'm sorry to say that your UNC tests will need repeating because it would have been easy to mess that up with the changes I made.  One tricky thing is the case where the current drive is UNC and an absolute path on the current drive is specified (ie. starting with a single "/") -- I think I got this right, that I need to keep both the server and the share name from the UNC drive, then add the absolute path after those.  Also, I couldn't test the case where a relative path on a different drive was specified because I only have one drive.

- Phil

[FrankB]

Great Phil,

I'll test it later on today.

Frank

[FrankB]

Hi Phil,

compiler error:

Undefined subroutine Image::ExifTool::ContainsWildcards called at C:\Program Files\ExifTool\exiftool_files/lib/Image/ExifTool.pm line 5485

ContainsWildcards is removed from .pm, but still referenced from .pl
lines
1055
1441
4071
4197

Do I also need an updated exiftool.pl?

[Phil Harvey]

Oh, sorry.  I renamed ContainsWildcards to HasWildcards.  That should be the only change.

- Phil

[FrankB]

Ok.

I'll try that later.

[Phil Harvey]

Hold off testing until I come up with a fix for a bug I just found.

- Phil

[Phil Harvey]

Here's the fix ("test6" release).  You'll still have to rename IncludesWildcards to HasWildcards in exiftool.pl

Wow, what a pain in the ass this is.  I can see why the Perl porters gave up on trying to support the Windows filename quirks. 

I really appreciate your help here.

- Phil

[FrankB]

Will do. Not at home right now. Could take a few hours.

Glad to help

[FrankB]

Hi Phil,

I would say leave it like it is. All tests I could think of are OK.

Directory on Harddrive
< 260 Chars relative and absolute path
> 260 Chars relative and absolute path

Directory on Server (UNC)
< 260 Chars relative and absolute path
> 260 Chars relative and absolute path

Played with . and .. OK

This scenario also:
Working directory in CMD prompt c:\users....
Last directory on Z: is \Long dirxxxx (>240 chars)
exiftool -filename z:*.jpg will not read 2 files
exiftool -api windowslongpath=1 -filename z:*.jpg will read all files

For UNC paths this does not work, because CMD has no notion of a working directory for a UNC path. (It can be done maybe with PowerShell, dont know)

Executed commands in GUI, CMD prompt and PowerShell, with and without Api Debug

Only thing that I noticed, but not an error. Prepending on a harddrive is only done when the path name > 250 chars(approx). For UNC paths, and absolute paths it is always done. (To prove that I really tested!)

If there is some specific scenario that you want tested, let me know.

Thanks so far Phil,
Frank

[Phil Harvey]

Hi Frank,

Excellent, thanks!

Yes, I'm not adding the "\\?\" prefix unless the length gets close the the limit, or if it is needed for a UNC drive.  I liked the suggestion of yours to add it only if necessary.  I set a slightly lower threshold because after doing some research it seems that there are times the limit is less than 260, so I set it a 247 which is the lowest value I saw.

- Phil