0

This is a problem which has a thousand posts across the internet but I can't find answers that are specifically suited for GUI + verified move/copy, so it doesn't look like a duplicate question.

I want to use a GUI based verified move/copy file manager. If it wasn't for long paths and verification, this would be easy - many file managers allow hash verified file move/copy, and many file managers allow UNC and attempt to work around long path issues. My primary setup for this is Windows 8.1+FreeBSD 11 +Samba 4.6.

The difficulty is that I haven't found a way to do this that is reliable. Even my go-to long filename managers with verification such as XYPlorer and FasyCopy fall over on long paths where I wouldn't have expected it.

So I'm looking for approaches that ideally avoid the Windows API entirely except for local files, so that I can manage the remote files without worrying about path length. But here again its difficult: GUI based SCP (WinSCP, Filezilla) would be fine, except that these don't formally do hash verification of the source and target after move/copy, and FISH which might help move the file activity to the server, doesn't have a full Windows client.

The functionality I'm after is move/copy/rename within a share, between shares on a single machine, between shares on different machines, and between Windows and a share, but in each case avoiding the Windows APIs for remote file access if they can't properly handle long paths.

The other benefit I'm looking for is to execute server-side file activity directly on the server and off the network, again verified where data is physically written or moved.

Unfortunately I've found that even programs that state they handle long paths don't seem to do it well. When I do file move/copy using them, it helps a bit but I often get a bunch of errors that suggest they're still having problems with handling long paths in practice, and I don't want to have to constantly doubt my data copy/move integrity or move things to temp locations just to manipulate them when the remote store doesn't actually have long path issues with it.

I'm looking for a way to knock this on the head, but what techniques might help? I don't want to reduce file paths or use CLI in this case (which wouldn't be easy anyhow here), using drive letter mapping doesn't seem to help much or would need too many letters, using "\\?\" would help if the issue was with local not remote files as the remote ones are already UNC, SCP doesn't usually include explicit verification, especially in GUI file managers......

I haven't tried setting up X Windows so I'm working in GUI directly on the server when its a server file, but this wouldn't help for Windows to/from remote. I also haven't looked at file managers that allow copy extensions - for example those that allow extra copy/move methods (such as ADB or shell command equivalents) to be added as a script or similar. Beyond that I'm out of ideas.

What options might I have overlooked?

Improve this question
5
  • "I don't want to reduce file paths" there is your problem. You are trying to use 3rd party programs to work around inbuilt Windows API restrictions. It's not surprising most of them don't work under some edge cases.
    – DavidPostill ♦
    Jul 2, 2017 at 11:40
  • For the purpose of the question, can we view "the problem" as being reliable file management with long paths, rather that user working practices? Almost every problem could otherwise be "solved" by recastng the user's view of the issue as "the problem" and defining the need for the user to change as "the solution". I'm aware of the option but it's not really helpful since backups, automated snapshots, saved web pages with long names, expanded existing archive files (expanded zip/tar/rar/iso), and descriptive file names and versions, mean choosing between long paths, less intuitive working meth
    – Stilez
    Jul 2, 2017 at 13:19
  • ...ods, or less easily searched and recognised files in routine use. I'd like to find a better way for the system to fit the use, not chop the use down, in the first instance, and a "known good" workaround would be useful.
    – Stilez
    Jul 2, 2017 at 13:23
  • I don't have an answer, but here's what I know. superuser.com/questions/216704/… robocopy can reliably copy files with guaranteed completion. If it fails due to broken connection etc. it can be restarted, on the same copy task, without recopying already transferred files. I would look for a GUI on top of Robocopy: google: "robocopy gui" gives me: technet.microsoft.com/en-us/library/… technet.microsoft.com/en-us/library/… YMMV.
    – user19496
    May 1, 2018 at 11:11
  • There's at least a 32k API for network files on Samba/SMB and I think it can also be used for local disks as well (a user can enter \\?\ to access the file through that API, I think?). So it seems that Windows actually allows paths up to 32k, just that most file managers either are not GUI, or don't reliably use the long path/name APIs for everything, or don't do verified copy - hence my question. I'm looking for one that's all of those. But I'm pretty sure the limit isn't ~ 256 chars
    – Stilez
    May 1, 2018 at 12:17

1 Answer 1

Reset to default
0

Not sure why nobody has mentioned this yet but I found the easier (though a bit slower) method is to just zip the folder, copy the zip, and unzip it. Note that you I use a 3rd party zip program like 7zip, the windows built in program might have the same file path restrictions. Alternatively you can move the heavily nested folder up to a higher-level directory, copy it over, and then move it back to it's nested location.

Not sure why this works, but according to this article windows has a max length for file name, but for some reason during copy operations it checks the length of the entire file path.

Improve this answer
2
  • The problem with this is, yes it works. But no it's completely impractical for general use as a "main" file manager system. Occasional use may work, but imagine when you want a method that "just works", to use for all file movement, which might be quite a constant need. This would be completely impractical.
    – Stilez
    Sep 15, 2018 at 23:04
  • True, I was only running into the path issue for a few folders so it wasn't a big deal for me, and I didn't want to download other 3rd party software like FastCopy or fiddle around with robocopy. But you said you were having issues with FastCopy? Why would that be? And have you tried robocopy GUIs?
    – woojoo666
    Sep 16, 2018 at 0:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.