Advanced Move - using Windows or did you roll your own?

[therube]

Advanced Move - using Windows api's or did you roll your own?

Cause I ran into a "lfn" issue.
Odd one at that.

full-path-name was > 255
name was 170
& multiple path parts made up the rest

Anyhow, Windows & Everything (Advanced Move) did not want to move from existing path/name to a (wanted, shorter) path (name).

[horst.epp]

I have no problems with Everything Version 1.5.0.1258a (x64) Advanced Move
using a file name that long and a very long path moving it into some shorter path.

Also file manager Total Commander handles such overlong pathes without problems.

[void]

Advanced Move will use the system to move files with IFileOperation.

This API has MAX_PATH/259 character limits.

I've put on my TODO list to handle moving of files with very long filenames with MoveFileEx.

[horst.epp]

Advanced Move will use the system to move files with IFileOperation.

This API has MAX_PATH/259 character limits.

I've put on my TODO list to handle moving of files with very long filenames with MoveFileEx.

There is some Windows setting which removes this limit for Windows 10.
I did this some time ago and Everything advanced move handles much longer pathnames for me without problems.
https://docs.microsoft.com/en-us/window ... n?tabs=cmd

[void]

There is some Windows setting which removes this limit for Windows 10.
I did this some time ago and Everything advanced move handles much longer pathnames for me without problems.
https://docs.microsoft.com/en-us/window ... n?tabs=cmd

This only affects the native win32 APIs.
The shell is still limited to 259 characters.

Using short path-names makes it possible to bypass this limit. eg: c:\progra~1\common~1\a really long filename.txt
However, in therube's case above, the short path is still too long.

Everything 1.5.0.1259a will now check for really long paths and handle these separately with the native win32 API calls.

Currently, no dialog or progress will be shown for moving/copying files with really long filenames.

[horst.epp]

There is some Windows setting which removes this limit for Windows 10.
I did this some time ago and Everything advanced move handles much longer pathnames for me without problems.
https://docs.microsoft.com/en-us/window ... n?tabs=cmd

This only affects the native win32 APIs.
The shell is still limited to 259 characters.

Using short path-names makes it possible to bypass this limit. eg: c:\progra~1\common~1\a really long filename.txt
However, in therube's case above, the short path is still too long.

Everything 1.5.0.1259a will now check for really long paths and handle these separately with the native win32 API calls.

Currently, no dialog or progress will be shown for moving/copying files with really long filenames.

But why did all my tests with overlong filenames and pathnames worked in Everything ?
Test where done with 1.5.0.1258a

[void]

It depends on the implementaion of IFileOperation.
It's possible Windows 10 does manage really long paths for operations on file systems.

Everything will use the short path when the long path exceeds 259 characters when working with the shell.
You might have a long path that is 370 characters long with a short path of only 215 characters
eg: C:\Program Files\Common Files\Just an example....\a really long filename.txt => C:\Progra~1\Common~1\Just a~1\a really long filename.txt
A file that has a really long filename may still have a short path with a length of 259 characters or less and be usable with the shell API without issue (mostly -can run into issue when an implementer tries to get the long path with a small buffer).

There's a short path column available in Everything 1.5.
See if you can rename files found with the following search:
path:len:>259 len:shortpath:>259

[therube]

Everything 1.5.0.1259a will now check for really long paths and handle these separately with the native win32 API calls.

Does long paths also mean long filenames?


As it is didn't seem to work with a LFN filename.
(Not sure about the path itself, but I'm thinking it was probably not an issue.)

Edit Move (Copy) to... | Edit Advanced Move (Copy) to...
LFN (filename) didn't work
Would be nice if it used SFN (filename) to accomplish the move/copy

[void]

Yes, long paths = long filenames = LFNs.

Everything handles LFNs moves/copies itself.

Currently, LFN move/copy errors are silent.
I have added an error dialog for the next alpha update.

The destination filename might already exist?
The file might have been opened?
Will be interesting to see the error code with the next alpha update.

[therube]

> The destination filename might already exist?

No. Copying to (otherwise) empty directory.

> The file might have been opened?

Not sure? Could have been?
But in this case, oh, & I'm pretty sure - maybe I'm not... ? Now I'm not sure if it were a Copy or a Move?

If it were a Copy, I'd think the file being open shouldn't be an issue.
If it were a Move, yes, that could be an issue.

[therube]

i'm now thinking that maybe the file was in fact Open,
& being Open & with that silent failure, that led me to not even consider that the file was open

as it is, it looks like (with the file being Open),
a Copy does work as expected
a Move fails silently

so i must have been attempting a Move (with the [LFN] file Open)

& actually, with a SFN, you are alerted:
The action can't be completed because the file is open in...
Close the file and try again.
(^-- /that/ was actually a "Move" across volumes [so a Copy/delete], I: to Y:, if that matters?)


& in that regard, a dialog message altering you to the failure will certainly be of benefit

[void]

Everything 1.5.0.1271a will now display any error messages when copying/moving Long File Names (LFNs).

Please let me know the error code if you run into this issue again.