LFN deletion

[therube]

LFN deletion

deletion of LFN, or mixed LFN & SFN...
/may/ automatically select to permanently delete said files
or
/may/ attempt to delete SFN & permanently delete LFN

- it may not be particularly apparent to a user what might
be happening, & if they're not paying attention, they may
end up permanently deleting when they weren't looking to
do that at all, or they may expect that SFN goes to Recycle Bin
& LFN gets permanant delete - but that might not be the case...

Code: Select all

SFN... path parts  46 + name part  66, total 112 (that's short for me ;-))
LFN... part parts 110 + name part 193, total 303 (ditto ;-))

sfn/lfn, DEL, move 2 items to Recycle Bin?
YES
(followed up by)
Are you sure you want to PERMANENTLY delete these 2 items
YES
(at that point, SFN *was* PERMANENTLY deleted)
(then)
Destination Path Too Long:
the file name(s) would be too long for the destination folder... (Skip | Cancel)


i'm pretty sure, well maybe*, different combinations, maybe orderings, are apt to present
different scenarios as to what might or might not happen?

in any case, it's potentially a sort of a mess

given above circumstances, would have expected at least that the SFN was deleted to
Recycle Bin & a (Windows) prompt regarding LFN (being too long)

if i'm recalling, well maybe*, earlier 1.5's would have worked in that manner?

1263.

[void]

The following error is shown if you try to delete a folder with a really long filename:



This dialog is shown by the shell (not Everything).
I agree, it is dangerous to prompt to permanently delete when the user initiated a delete to recycle bin action.
An error dialog would be preferred.

It is easier to reproduce the issue with a long folder name than a file, as the folder name is preserved when moving it to the recycle bin.

I will consider an option to override the shell permanently delete dialog and show an error instead, forcing the user to shift + delete.


Earlier versions of 1.5 handled really long filenames on its own.
Current versions will use the shell if the short path is less than 260 characters.

Disable shell_short_path if you want this old behavior.
If disabled, you will lose a lot of the nice shell dialogs for really long filenames.

[reddevil]

Windows 10 now allows long path file names via group policy or regedit.

To enable Win10 more than 260 length long path names, set in regedit:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem]
"LongPathsEnabled"=dword:00000001

To disable:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem]
"LongPathsEnabled"=dword:00000000

How will the above scenario behave with the registry hack enabling long paths?

[void]

These settings only apply to low level Windows API calls.

The Windows shell is still limited to 260 characters (including the nul character).

Short paths can be used to get around this limit in some cases.

Enabling LongPathsEnabled might help indirectly when the short-paths are expanded.

[therube]

I'll just throw this in... might be the same situation, or maybe different, not sure...


(soft) DEL (single) LFN (file)
- Are you sure you want to PERMANENTLY delete this file?

IOW,
the action you started was a SOFT delete
the action you're prompted about is a HARD delete

- easy to miss...

(now, it won't work, delete, in any case, because it seems the action actually
/attempted/ IS a SOFT delete - which won't work with a LFN)

- so i guess there is an error here on the catch & the HARD delete /message/ ?

[void]

This "PERMANENTLY delete" dialog is shown by Windows, not Everything.

It is a tricky one to catch, because Windows can move some LFN files to the recycle bin with the short path, while others will fail with the "PERMANENTLY delete" dialog.


I will trial throwing a hard error if you try to delete a LFN file with the next alpha update.