LFN handling Changes, 817b?

General discussion related to "Everything".
therube
Posts: 1607
Joined: Thu Sep 03, 2009 6:48 pm

LFN handling Changes, 817b?

Postby therube » Sun Dec 04, 2016 10:52 pm

LFN handling Changes, 817b?


Have there been changes in LFN handling (at least by 817b)?


LFN as in > then ..., ~283 chars in this case.

What was I doing...
A rename I think?
But it seemed...

No, that wasn't it, the file was open my audio/movie player, MPlayer, [& so "locked", which I didn't realize at first] & an attempt to rename should have failed - regardless of SFN or LFN, & it did, but silently in this case [LFN].

An attempt with a SFN gives [Win7]:

"The action can't be completed because the file is open in MPlayer.
Close the file & try again.

Try again. Cancel"


Then I check in debug & I see:

ParseDisplayName \\?\I:\...279.mp4

Then later:

MoveFileExW(): GetLastError(): 32: Failed to move file from I:\...279.mp4 to I:\...279-testing.mp4

So in one spot \\?\I:\ is used, in another I:\ is being used.


With the file open in another application (& so "locked"), the Rename fails.
SFN: Fails with an expected Windows error message
LFN: Fails silently


It would be nice to get a Fail notification in both cases.
And if not from Windows, could Everything throw one out at us?


(Now thinking, its just something I hadn't noticed before?)
(Doesn't LFN handling really suck in Windows!)


Note that had the file not been locked, the rename would have succeed - even with a LFN, because \\?\ would handle it correctly.

void
Site Admin
Posts: 3171
Joined: Fri Oct 16, 2009 11:31 pm

Re: LFN handling Changes, 817b?

Postby void » Sun Dec 04, 2016 11:44 pm

No change to LFN handling in 817b.

Everything attempts to use its own rename first, if this rename fails, Everything will fall back to the OS implementation.

What is happening here is Everything's renamer fails (file is locked), Everything then calls the OS implementation, which just fails with no error (path too long).

Really the OS should be displaying a UI error message, as I asked it to.
It's an issue with Windows..

I could detect really long file names before passing to Windows, but Windows may end up adding support for them in a future release.
What I should do is catch certain errors (eg: 32 - file locked) and display my own error message -added to my TODO list..
Currently I'm using the OS to display error messages and handle other conflict dialogs, retry, cancel dialogs etc..

The renamer in Everything supports upto 32000 characters by prefixing really long file names with \\?\

therube
Posts: 1607
Joined: Thu Sep 03, 2009 6:48 pm

Re: LFN handling Changes, 817b?

Postby therube » Sat Mar 18, 2017 12:27 pm

The renamer in Everything supports up to 32000 characters by prefixing really long file names with \\?\

Just how does that come into play, just how do you go about using that?

void
Site Admin
Posts: 3171
Joined: Fri Oct 16, 2009 11:31 pm

Re: LFN handling Changes, 817b?

Postby void » Sat Mar 18, 2017 1:51 pm

Whenever Everything converts an internal UTF-8 string to a windows wide char filename, Everything will check the length of the string and if it is longer than 260 characters, it will prefix it with \\?\
Basically any time Everything deals with a filename in an OS call this will happen.

For example:
\\?\D:\very long path

Please see Maximum Path Length Limitation in:
https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247%28v=vs.85%29.aspx

therube
Posts: 1607
Joined: Thu Sep 03, 2009 6:48 pm

Re: LFN handling Changes, 817b?

Postby therube » Sat Mar 18, 2017 6:57 pm

OK, so it's all done internally.

Any reason to be able to allow \\?\ in a search?

Code: Select all

\\?\C:\TMP
\\?\C:\<some long path >260>\TMP


Code: Select all

C:\>  DIR \\?\C:\TMP,  works.
C:\>  DIR \\?\C:\<some long path >260>\TMP,  fails.

(I suppose the last failure is expected.)

therube
Posts: 1607
Joined: Thu Sep 03, 2009 6:48 pm

Re: LFN handling Changes, 817b?

Postby therube » Sat Mar 18, 2017 7:00 pm

Can...

Edit | <Copy | Move> to Folder...
Edit | Advanced --> <Copy | Move> to Folder

use the same facility?

That would be of benefit.

void
Site Admin
Posts: 3171
Joined: Fri Oct 16, 2009 11:31 pm

Re: LFN handling Changes, 817b?

Postby void » Sun Mar 19, 2017 9:49 am

Added to my TODO list.

void
Site Admin
Posts: 3171
Joined: Fri Oct 16, 2009 11:31 pm

Re: LFN handling Changes, 817b?

Postby void » Mon Mar 20, 2017 10:16 am

In Everything, Delete, Copy to, Move to, Advanced Copy to and Advanced Move to all use an internal windows API call, called SHFileOperation.

This function does not support \\?\

I'll have to implement my own delete, copy to, move to dialog, which is on my TODO list.


Return to “General”