LFN handling Changes, 817b?

[therube]

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]

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]

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]

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/librar ... 85%29.aspx

[therube]

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]

Can...

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

use the same facility?

That would be of benefit.

[void]

Added to my TODO list.

[void]

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.

[therube]

Not sure what to expect?
(What I got was a silent fail, F2 Rename.)
Source path+name happened to be at 260 chars.
Renamed would (have) be longer.
Looks like <=262 is OK, >262 fails?

Code: Select all

Everything
Version 1.4.1.938 (x86)
Windows NT 6.1
Processors 4
IsAdmin 0
AppData 0
Service 1
cmdline "C:\DEV\Locate\Everything.exe"
rename:
I:\..... ... .. ........-.... ...... .. ... .... .... ...   ...... ...... .... .
.. ... ......, ..... ..... ........ ..... ..... ...... ... .... ..... ...... & .
.... ...... .....   ..... .........  ........ ... - ...........-......-...-.....
...-..-.._MUX_AV.TXT
to:
I:\..... ... .. ........-.... ...... .. ... .... .... ...   ...... ...... .... .
.. ... ......, ..... ..... ........ ..... ..... ...... ... .... ..... ...... & .
.... ...... .....   ..... .........  ........ ... - ...........-......-...-.....
...-..-.._MUX_AV 999.TXT
MoveFileExW(): GetLastError(): 123: Failed to move file from I:\... to I:\...
WM_ACTIVATE 00000000 00e70946, lastfocus 009107e8, current focus 006b01e8
Enter SHFileOperation
Leave SHFileOperation 124 0

MoveFileExA function

Somehow, I must have ended up, at some point, with a longer lfn, because when I tried to open the file, I got a message - don't ask me what it said ? perhaps "missing" or something like that?
Even opening the directory (from within Everything) with Windows Explorer at that point failed to open the file (double-click).
At that point, I was going to move the file to its parent directory (saving a few chars) but decided not to do that, then renamed the file name shorter - using Everything, at which point I was then able to open it, again.

But that kind of doesn't make sense, because if I can't rename it longer, why was I able to rename it shorter?

I do have a "ghost" process - unrelated to the file in question... nope, killing it made on difference.

[void]

Is the filename without the path longer than 255? -There is a limit of 255 characters for a filename.

Was "I:\..... ... .. ........-.... ...... .. ... .... .... ... ...... ...... .... .
.. ... ......, ..... ..... ........ ..... ..... ...... ... .... ..... ...... & .
.... ...... ..... ..... ......... ........ ... - ...........-......-...-.....
...-..-.._MUX_AV.TXT" the real filename? or did you change the filename to dots for this post? if this is the real name, it seems impossible because the basename is longer than 255 characters. I'm counting 257 characters. 260 with the I:\ prefix

Everything first tries to rename the file with an OS Call MoveFileEx, but fails:
MoveFileExW(): GetLastError(): 123: ERROR_INVALID_NAME The filename, directory name, or volume label syntax is incorrect.

Everything then tries to rename with SHFileOperation (aka the shell), but fails:
Leave SHFileOperation 124 0: DE_INVALIDFILES 0x7C The path in the source or destination or both was invalid.

Usually SHFileOperation provides the user with any error information. Unfortunately, in this case it fails silently.

[therube]

Path part is 7 chars, I:\456\
(Yes, I renamed the name to .'s, s/[A-z]/\./g)

Currently, name part is 249 chars.
At some point, name part was at least 253 chars.
It seems the longest name that part I had been able to use was 255 chars - as you said.

And 255 + 7 = the 262 I was hitting above, but the real issue was >255 in the name part.

Sigh.


(New math. 255 > 32,767 .)