Copyfile with long path names

There seems to exist a limitation for the length of the file path when using the copyfile-command (something like 260 characters), because I get an 'Unknown error' when I want to copy to a destination with a longer path.

This seems to be related to a problem with the Windows copy+paste command (because I cannot even manually copy the files to that location). I googled the problem and it seems that there exist some workarounds for manual copy+paste. Do you know of any workarounds for this problem in Matlab?

My system: Windows 7 64-bit Matlab R2013a

[K E]

Can someone point to where "Long path tool" can be found? I don't see it in the file exchange.

[Walter Roberson]

The references to "Long path tool" were spam. :(

[Jan]

I'm not sure if an automatic deleteing is necessarily a fix of the problems.

[jack reacher]

Enable long file name support in Windows 10

[Walter Roberson]

Long filename support still has a limit of something like 259 or 260, unless you use the \\?\ noted below.

Answer 1

[Jan]

It is not a problem of Copy&Paste, but file names have this general limitation under Windows. E.g. the Windows Explorer cannot move files to the recycle bin, if their name is longer.

As workaround you can use the Windows API function and mask the name with the leading magic string '\\?\'. But a lot of important functions (like the already mentioned recycling) will not work. Even e.g. DIR fails for too long path and/or folder names (at least here the masking works, see also FEX: GetFullPath). Therefore I suggest three strategies:

1. Write an enhancement request to Microsoft. This is such a dull and idiotic limitation, which blocks a serious using of the system since the first DOS implementations. Try to reach Bill Gates personally, because he is responsible.
2. Use a serious operating system for serious tasks. Linux, Unix, Aix, BeOS, HP-UX, MacOS (7,8,9,X), Minix, BSD, Solaris, VMS, and even the Sinclair ZX Spectrum (1982) had no such limits in the file name length.
3. Use shorter file names, when you insist on using Windows for considerable reasons.

Note that very long file names usually mean, that the user inserts important information into the name, instead of storing it in the contents. But it is not efficient to store important information in the filesystem's name tables. A slightly exaggerated example: You can even store pictures in the name tables by using spaces and X as black&white pixels and using a very small font size for the command window, where the LS command is called. But then you cannot blame the OS, if you cannot use duplicate pixel rows or if the output is dosplayed in alphabetical order.

PS. Sometimes I think of inserting smilies in my messages, but I still hope my English is distinct enough to let the readers understand the intention without such extra markers. Of course I know, that Bill will no answer, but I'm impressed every time TMWs technical support responses to such enhancement requests.

[jack reacher]

use robocopy

[Walter Roberson]

robocopy appears to refer to https://technet.microsoft.com/en-us/library/cc733145(v=ws.11).aspx

Answer 2

[Friedrich]

Hi,

have you tried to prefix \\?\ for the file path like mentioned here:

http://msdn.microsoft.com/en-us/library/aa365247%28VS.85%29.aspx

AFAIK MATLAB calls into the WIndows API function when using copyfile. At least my MATLAB doesnt complain when I build up a file path like

a = '\\?\C:\myfolder\test.dat'
copfyile(a,'C:\demo.dat')

And it also works. Does this work for you?

[Christoph]

Thanks for pointing this out! I tried it with the prefix, but I keep getting strange errors. Depending on several parameters (prefix for source or destination only or for both, within cellfun or not, in debug mode or not, 'f' flag passed or not, copying full folders or just files,...) I get a variety of error messages ('Unknown error', 'Wrong syntax for path', 'System could not find path', 'Could not create already existing file'), and I cannot even figure out how these parameters influence the type of error message that I get.

Do you know the code for directly using the Windows API, so I can try to build my own copy-function?

[Jan]

Even the Windows API is restricted to MAX_PATH characters, as I have written already. While the ANSI version of CopyFile accepts MAX_PATH (260) characters only, the Unicode version CopyfileW accepts up to 32,767 characters, when you provide the leading magic string also. And the same for CopyFileEx.

Moving a file with a long name or path to the recycle bin ShFileOperation will not work at all. Even the displaying in the Windows Explorer can fail. Therefore the Windows API is the actual problem and not a solution.

[Friedrich]

At least this \\?\ prefix works for me with a path longer than 260 characters:

>> file = fullfile(pwd,'bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb','test.txt');
>> numel(file)

ans =

     285

>> exist('D:\test1.txt','file')

ans =

       0

>> copyfile(strcat('\\?\',file),'D:\test1.txt')
>> exist('D:\test1.txt','file')

ans =

       2

When I don't add the \\?\ prefix I get an error:

    >> copyfile(file,'D:\test1.txt')
    Error using copyfile
    No matching files were found.

[Jan]

The magic (another word for ugly here) string '\\?\' helps also, for scanning folders with long pathes by the DIR command. Unfortunately it is not the 260 characters limit, but some characters less. The length of the file names might matter also, but it cannot be known before getting the list. After some user requests, I've expanded GetFullPath, such that it can handle this securely:

List = dir(GetFullPath(Folder, 'fat'));

[KAE]

In case it helps someone else, here is an example for the move command if you need to move a file with a long name to a subdirectory resulting in an even longer name so that the final filename would exceed the 260 character limit. There are double quotes to deal with spaces in the file or directory name.

    eval(['!move "\\?\' longFilename '" "' subdirectoryMakingLongerFilename '"']);

Answer 3

[Iain]

I'm not sure how you can reasonably use this or if it still exists in Win7.

There is a "short" name for every file and folder, which is restricted to 8 characters.

C:\docume~1\ is the short path for C:\documents and settings\.

It gets extremely hard to use if you have huge numbers of similarly named files, because the "~1" part gets longer and more complicated.

[Jan]

Fortunately the Windows API offers method to get the short name automatically, such that a simple Mex-File can achieve the conversion. But even the short name must fail, when the path of a file is deeply nested and even the resulting short name exceeds MAX_PATH characters. In addition error messages containing the abbrev. filename will look such ugly.