[64-bit] Handling files/folders with overlong pathnames lead to crash

[daniel_m]

When handling files/folders with overlong paths, XYplorer (v28.00.0534 x64, fresh install, Win 10, scaling 100%) crashes instantly. I set "LogToFile=4", but the crash happens before a logfile could be written. With handling, I mean drag & drop, but right-click cut and paste can trigger a crash as well.

How to reproduce:
Create a folder with a very long name (254 characters), like "HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH" and create a New Text File.txt inside that folder. Try to drag the text file anywhere => XYplorer crashes

XYplorer can still rename items with overlong pathnames.


When creating a file or folder and giving it a name with >= 255 characters, XYplorer becomes unresponsive and may crash before the naming can be cancelled by pressing ESC. When this is happening, the XYplorer titlebar flashes (turning active and inactive frequently). It looks like it was trying to show an error message, but fails. This also causes high CPU usage.

I tested v27.20.0200 x86, and found that it somewhat more robust in handling overlong pathnames, but it does crash as well.


It seems a good idea to prevent users from giving files or folders names exceeding 255 characters by showing a corresponding error message and refusing to actually write that name to the file system. It would be great if XYplorer could handle pathnames exceeding 255 characters. This can happen accidentally, e.g. when extracting an archive into a nested folder, especially when the archive contains (nested) folders with long names.

[daniel_m]

Hm, I did some more testing, and XYplorer doesn't always crash. Like, I created a folder with 254 characters inside a folder with 254 characters, and created a new text file inside. I was able to drag that text file to another folder successfully. But, testing some more, I still get XYplorer to crash, e.g. by creating a new folder inside the overlong subfolder, or by double clicking the tab background to go up one level/folder.

So, XYplorer does have the potential to handle these weird situations. It's just that something goes wrong sometimes.

[admin]

Confirmed, the 64-bit version has a problem with dragging overlong items. I'll inform the tB makers...

[admin]

XYplorer handles overlong items for many years. Your issues come as a surprise.

The crash by dragging should be fixed in v28.00.0555.
Do you still get other overlong-related crashes in v28.00.0555?

[daniel_m]

XYplorer v28.00.0558 handles overlong pathnames very well, as long as individual file and folder names (including extension) are <=254 characters. Thanks a lot! I created five nested folders with 254 characters each, and creating and dragging files and folders within the lowest folder did not crash XYplorer. I did not test the limits ... a 2500 characters long pathname should cover most (unintended) shenanigans

There are still some quirks left, and one does crash XYplorer, but you decide yourself if you think they are worth fixing. I included them for the sake of completeness.

(1) Creating a file or folder with >=256 characters still crashes XYplorer with a wildly blinking titlebar (if the action can't be cancelled quickly enough by pressing ESC). I recorded my screen and managed to capture the pop-up XYplorer displays before it crashes:

error.png (3.44 KiB) Viewed 167 times

(2) XYplorer allows the creation of files or folders with 255 characters, but fails to delete them. The log says "Completed 12 mins ago after less than 1 sec (canceled or failed) ...". XYplorer can rename these files or folders, and it can delete them when their names (including extension) is <=254 characters long.

In both cases,(1) and (2), an error message telling the user that they have to (re)name a file or folder to less than 255 characters would be helpful. And the crash with >=256 characters could be prevented by not attempting to create the file or folder and pester the user with the error message until they comply I doubt this is a problem anyone ever encounters, and I only found out by deliberately attempting something insane ... or more insane than some other stuff that XYplorer enables us to do, in contrast to the ever so crappy Windows Explorer

[admin]

1) How do you try to create that folder?

2) Fixed in next beta.

[daniel_m]

1) Ah right, I should have tested with a fresh instance. Now it got more complicated

Firstly, it doesn't make a difference whether i paste a long string as the name, or if I type the string by holding down a letter key.

Secondly, when I click onto some empty space in the list view to (try to) make XYplorer create the file/folder, it simply refuses to do so and the cursor is back in the name field.
But! When I click onto empty space repeatedly (without double-clicking!), I can provoke a titlebar blinking frenzy eventually. Sometimes it takes three clicks, sometimes ten. A sure way to get the titlebar frenzy is to try to make XYplorer create the file/folder by pressing ENTER.
Once the titlebar is blinking (XYplorer uses 100% CPU at that point), pressing ESC is likely to crash XYplorer (and show the "cancel all transfers..." message just before the crash).

So, right-click > New Folder > paste 256 character string into name field > press ENTER > press ESC (sometimes ESC cancels, most of the times it crashes)

I found that switching to another program will stop the titlebar blinking and let me edit the file/folder name again. This is best done with ALT+TAB, as clicking onto another program takes several clicks. Looks like a race condition where XYplorer gains focus with every titlebar blink, and the mouse click onto another program has to be made in between blinks (or something like that).

[admin]

Okay, the next beta should be crash-proof.

[daniel_m]

So good to see that XYplorer continues to be so much better than any other file explorer.
The error message for a >=255 characters name in v28.00.0567 works very well.

The bug that prevents deleting files/folder with names that have 255 characters still seems to be present. The changelog for v28.00.0564 mentions Win 11, but not Win 10 (which I still use despite the EOL situation). But ... I am more than happy that crashes are fixed and don't think the specific case of 255 characters would ever bother anyone. (Again, just reporting for completion and not asking for a fix. If you are the type of person who is bothered by being 0.00000000001% shy of 100% ... I am sorry for causing trouble )

[admin]

Give me the full path + name of an item you cannot delete. And describe how you try to delete it. Press DEL?

[daniel_m]

Code: Select all

D:\iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii

I tried right-click context menu > (shift) Delete, menu File > (shift) Delete, and keyboard (shift) DEL. All fail with a log entry "Completed X mins ago after 2 secs (canceled or failed)", but no error message to alert the unsuspecting muppet user.
Menu File Special > Delete Long does work as expected. Although ... with all the recent fixes, Delete Long seems obsolete?

[admin]

Interesting! A 255-character path in the drive root (which is totally legal) seems to be something Microsoft did not expect.

Win8.1 / XY32: Delete to recycler OKAY.
Win8.1 / XY32: Restore deletion per Undo. FAIL, never ending restore dialog from Windows.
Win8.1 / XY32: Restore deletion from recycler per Restore in shell context menu: CRASH XY!
Win8.1 / File Explorer: Restore deletion from recycler per Restore in shell context menu: CRASH File Explorer!!!

Win11 / XY32: Delete to recycler (or permanent): FAIL (nothing happens apart from the main window flashing one time).
Win11 / File Explorer: Delete to recycler (or permanent): FAIL (nothing happens).

WOW.

I'll fix it for XY only. Sorry, Microsoft.

PS: The max length the shell can handle for root paths is X:\+245 characters (empirical findings on Win8.1)!

[daniel_m]

It's not just in the drive root but further down the file system inside other folders as well.

But, who's got time to fix their OS when there are more pressing matters to take care of ... like Clippy ... or AI Clippy