Movefile "the system cannot find the path specified" (Windows OS)

I'm writing a small file renaming function to reverse the order of a list of image files (code below). I've run into an error using movefile. I get the error "Error using movefile ... The system cannot find the path specified." on the first call of movefile.

Surprisingly, I found that if I change

[dirname '\' 'TEMP_' fnames{n1}]

to

['TEMP_' fnames{n1}]

in both movefile calls, it now works and no longer throws the error. However, this means the files are moved to the local directory and then back again, which is obviously pretty slow when working with files on a network!

I've got a feeling this is related to the path length limitations of Windows OS. I've spent some time trying to research workarounds for the path length limit, but haven't yet found anything comprehensive. If anyone has a link to good material on the subject please let me know.

function reverseImgStackDir()

% Select folder
dirname = uigetdir('C:\');

% Compile list of tif image files
fnames = dir([dirname '\*.tif']);
fnames = {fnames.name}';

% 1st pass - swap file names
for n1 = 1:length(fnames)
    % Index working from the end backwards
    n2 = length(fnames)+1 - n1;

      % Temporarily rename file
      movefile([dirname '\' fnames{n2}], [dirname '\' 'TEMP_' fnames{n1}])

end

% 2nd pass - remove temp qualifier
for n1 = 1:length(fnames)
    % Temporarily rename file
    movefile([dirname '\' 'TEMP_' fnames{n1}], [dirname '\' fnames{n1}])

end

[Guillaume]

Would adding just 5 characters take you over the MAX_PATH limit (260 characters)? I would suspect that's not the issue. What's a typical dirname value / length?

[Ben Mercer]

Yes, in fact some of the pathnames I've been trying are just below 260 characters. I've pretty much confirmed that this is the cause now.

I've been investigating further, and have a working solution which involves temporarily mapping a network drive programmatically from within Matlab. Seems like a yucky solution to me but to my knowledge it is the only workaround for the Windows path length limitation.

I might make a separate post about this workaround to get feedback on whether it is advisable/can be improved.

Answer 1

[Guillaume]

In addition to Jan's suggestion of the FileExchange files, since you're on Windows you can also delegate the renaming to .Net:

prefix = ['\\?\', dirname, '\'];  %\\?\ to enable paths longer than MAX_PATH
System.IO.File.Move([prefix, fnames{n2}], [prefix,  'TEMP_', fnames{n1}]);

See MSDN for the \\?\ notation.

[Ben Mercer]

Solved! Thanks Guillaume.

I had previously tried "\\?\", but it didn't work. The paths I am trying to access are on a network, so have the form "\\server\share". However, I found in the MSDN documentation "\\?\UNC\" can be used for network paths. Prefixing this onto my paths e.g. "\\?\UNC\sever\share" makes the problem go away!

Answer 2

[Jan]

If the length of the names matter, use https://www.mathworks.com/matlabcentral/fileexchange/28249-getfullpath, which inserts \\?\ in front of long names automatically.

In addition https://www.mathworks.com/matlabcentral/fileexchange/29569-filerename is much faster than movefile.

[Jan]

By the way, GetFullPath inserts also \\?\UNC\ automatically, if the resource is on a network share.

[Ben Mercer]

Brilliant - your function seems like the most robust way to solve this issue so I'll definitely be using that. Thanks

[Jan]

I've written this function to cope exactly with such difficulties automatically.

Answer 3

[Ameer Hamza]

Instead of constructing the complete path yourself, try to using fullfile(). It will properly construct the path by taking care of which slash to use ( \ for windows and / for mac)

path = fullfile(dirname, ['TEMP_' fnames{n1}]);

[Ben Mercer]

Indeed, using fullfile is better practice than hard coding the slashes - but it doesn't solve this particular issue. Fullfile constructs an identical path string to my code on a Windows OS.

One solution would be to run the code in a Linux environment, but my workplace doesn't allow me that luxury unfortunately :-(