Long path / filename (> 256 chars) does not open image

[nikagl]

System information:

• Windows OS version: Win10 1803, Build 17134.706
• ImageGlass version: 6.1.5.12

To Reproduce

Steps to reproduce the behavior:

1. Create folder path and filename with for instance 245 characters
2. Copy an image file to the path (total path needs to be >256 chars)
3. Open image

Actual behavior:

ImageGlass screen opens but remains empty

Expected behavior:

ImageGlass screen opens and shows image

Screenshots:

Longer than 256 chars: C:\Temp\This\Is\a\Folder\Structure\With\More\Than\256\Characters\Which\is\quite\difficult\to\create\as\it\requires\many\words\but\when\using\words\it\would\be\achievable\off\course\the\path\may\also\contain\spaces\which\works\fine\with\less\long\ThisIsATestFile.png

Shorter than 256 chars: C:\Temp\This\Is\a\Folder\Structure\With\More\Than\256\Characters\Which\is\quite\difficult\to\create\as\it\requires\many\words\but\when\using\words\it\would\be\achievable\off\course\the\path\may\also\contain\spaces\which\works\fine\with\ThisIsATestFile.png

Additional context:

Windows has multiple issues with path's longer than 256 characters (for instance creating a folder >256) but still, it's easily achievable when structuring screenshots of customer environments and such...

[fire-eggs]

I'm not in a position to dig into this right this instant, but here is a question.

Have you enabled Long Path support on your system? (As described here).

[fire-eggs]

There are several dimensions to this - more complex than I expected.

1. I'm not sure how IG is still running for you: I try this and IG consistently dies. Unless you're running 32-bit Windows.
2. I can't drag the file to IG: Windows won't let me. This does not change with Win10 Long Paths enabled (exception from the Shell).
3. I can't open the file via the File Dialog: Windows won't let me. With Win10 Long Paths enabled, I can open the file.
4. The library we are using to load images crashes with a native exception, which causes IG to shut down. This is true with or without long path support enabled. [Techie]The library we are using is a managed wrapper around a native library; the managed wrapper is failing to catch the native exception.

This is looking like a long-term "you can't do that" limitation.

1. I need to raise to Microsoft the fact that drag-and-drop with long paths fails.
2. I'll need to work with the library author to find out what their plans are for fixing this / supporting Win10 Long Paths. This is likely a limitation in the base library, so two groups to approach.
3. IG also needs to catch the native exception rather than die ignominiously.

In the meantime, the best workaround I can suggest is to use the SUBST command to provide IG with a short path to your various customer environments. Let me know if you need more detail.

[nikagl]

Have you enabled Long Path support on your system? (As described here).

Yes, tried it (including reboot), but didn't solve the issue...

1. I open IG using double click on the image file. It simply opens, but does not open the image file (you can see the missing title). Using 64-bit Win10.
2. Same issue
3. It doesn't open for me! I get the following error:

Drag/drop does work for stuff like command prompt. Not sure what other .net based tool I could use to test this?

Subst works fine, in my case I simply use the Windows Photo Viewer (which I like a lot less than IG!) which works fine, or move it into a smaller TEMP folder and move it back after viewing (in case of a lot of files)...

[fire-eggs]

Thanks @nikagl for the update! I think I have a partial solution, will update here if confirmed.

[fire-eggs]

Fix is ready, tested on Win10 and Win7 without problems. Allows opening an image by double-clicking.

Opening a long-file-path image via Open dialog will only work if long path support is enabled on Win10.

Drag-and-drop of file paths longer than 260 characters doesn't work under any circumstances; I'll enter a new issue to cover that case.

[nikagl]

Superb, let me know when a compiled release is available that I can test. I also noticed a weird bug where all pics in a folder are unreadable when you delete the first picture in a list. Closing IG fixes it (so no files are corrupt)... will create a bug report if it still occurs in next release...

[d2phap]

Hi @nikagl I have just uploaded IG Moon 6.1.5.25. Please help to check. https://imageglass.org/moon

Thanks

[nikagl]

Sorry, it didn't work for me after upgrading:

And win32 long paths is enabled:

[fire-eggs]

Thanks for the update. I messed up.

[fire-eggs]

Working good for Win10, even with "long path mode" disabled. Problems on Win7.

The latest IG-Moon (6.1.5.28) has the latest fix.

[fire-eggs]

Works for Win10, agreed to consider the Win7 part as a limitation. So this particular issue is ready.

[nikagl]

Works for Win10, agreed to consider the Win7 part as a limitation. So this particular issue is ready.

No sure how you tested, but Win10 does not work for me (6.1.5.28):

Regards,

Nika.

[fire-eggs]

Okaaaay, this is starting to have me doubting my sanity.

All I can tell you at this point is that a) 6.1.5.28 works fine on my dev box, Win10.1803, and b) 6.15.28 fails on another box, Win10.1809. Either my dev box has something special, or there is a Windows version difference. Back to debugging ...

To answer your implied question, this is how I'm testing:

Two cases, double-clicking an image file, with "long path support" ON and OFF:

1. In E:...\JPG Folder, the folder path is < 240 chars, but the folder+file path exceed 260.
2. In the path ending "New folder longer longer longe", this is the longest folder path Windows Explorer will let me create. Double-clicking on the image shown as selected, the full path is 309 characters.

[fire-eggs]

OK, here is what is going on.

In my testing, I was always using a long file path from my E:\ drive. Windows gave IG the image path in a useful format and that is the code in IG 6.1.5.28.

However, if the long file path is on the C:\ drive [presumably the boot drive], Windows gives IG the image path in a different format! This format is not consistent with the Windows 10 long path support. It is also the format which is a problem on Windows 7.

So I will not have a solution in IG for long paths on the C:\ drive any time soon.

The only workarounds I can suggest are:

1. Use a second drive for images.
2. Use the SUBST command to create a second drive, mapping part of a long path on C:\ to a virtual drive. I have confirmed this works with IG. It is possible to persist virtual drives across reboots via the registry.

[nikagl]

Bizarre! I would have never thought it could be caused by the drive I'm using. Weird stuff. Wonder why other tools (like the default Windows Photo Viewer) do not have an issue, but might just be a .net specific thing... well... at least kudos for trying and thanks for your great tool!

[d2phap]

Marked this as limitation and looking for help.

https://docs.microsoft.com/en-us/archive/blogs/jeremykuhne/net-4-6-2-and-long-paths-on-windows-10

[bucketcat]

Since this is still marked as open nearly half a decade later and I still have the issue I'm going to necro this issue.

Any updates, any workarounds on user end (besides renaming folder or moving deeply nested folders to top directory)?

I also found this which could maybe be useful for a future fix in regards to bypassing the 260 char path limit, includes both some janky workarounds and API's that support said functionality.

[donatopace]

Ti solve the issue you Need format a partition with "ReFs". REFs Is a new Microsoft file system.

Il mar 13 set 2022, 14:00 bucketcat @.***> ha scritto:

Since this is still marked as open nearly half a decade later and I still have the issue I'm going to necro this issue.

Any updates, any workarounds on user end (besides renaming folder or moving deeply nested paths to top directory)?

I also found this https://superuser.com/a/1165879 which could maybe be useful for a future fix in regards to bypassing the 260 char path limit, includes both some janky workarounds and API's that support said functionality.

— Reply to this email directly, view it on GitHub https://github.com/d2phap/ImageGlass/issues/530#issuecomment-1245312493, or unsubscribe https://github.com/notifications/unsubscribe-auth/AKKO2G2SPHC54BQ42DPHRWLV6BUHRANCNFSM4HOIFKDQ . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[d2phap]

Some people confirm that this issue is resolved in v9.0 beta: https://groups.google.com/g/imageglass/c/dzlrupO4dp4/m/GH0-zwc3AwAJ

This is probably because v9.0 beta uses .NET 6.0 which supports long path by default: https://github.com/dotnet/runtime/issues/14062#issuecomment-135933052

[d2phap]

Confirmed this issue is fixed in v9.0 beta 2