Filename Length Limit for Move Command

  • Thread starter Thread starter Steve
  • Start date Start date
S

Steve

Can anyone here confirm or refute that the Move command at the Windows
200 SP4 command prompt has a limit of around 128 characters on the
filename? I'm trying to build up a batch file that will handle some
file management tasks. Copy and then delete might work, but because of
the particular scenario takes many times longer than simply using Move
(the time is nontrivial because there are nearly 10K files involved).
There are a couple hundred files that don't move, and the common
thread seems to be that they have names longer than about 128 chars.
Is there another command, a utility, or perhaps an environment
variable setting I could change, to accomplish a Move of a file with a
long name, without resorting to copy-then-delete?

Steve Hendrix
 
The limit is on the whole path, not the filename itself. The path
cannot exceed 256 characters.

D:\<256 chars>NUL

John
 
Steve said:
Can anyone here confirm or refute that the Move command at the Windows
200 SP4 command prompt has a limit of around 128 characters on the
filename? I'm trying to build up a batch file that will handle some
file management tasks. Copy and then delete might work, but because of
the particular scenario takes many times longer than simply using Move
(the time is nontrivial because there are nearly 10K files involved).
There are a couple hundred files that don't move, and the common
thread seems to be that they have names longer than about 128 chars.
Is there another command, a utility, or perhaps an environment
variable setting I could change, to accomplish a Move of a file with a
long name, without resorting to copy-then-delete?

Steve Hendrix

As John says, the problem lies in the length of file name + path. This
means that all commands (including "copy") are affected, not just
the "move" command.

You could get around the issue by creating a mapped or substituted
drive that points into the middle of the excessively long path. I would
advise against this course of action because it will make it really
difficult for you to handle these files.
 
As John says, the problem lies in the length of file name + path. This
means that all commands (including "copy") are affected, not just
the "move" command.

I know about the 256 char command line limit, but that does not appear
to be the problem here. The files are all in a single directory whose
name is 8 characters and the directory is at the root level. Filenames
longer than about 128 chars are being skipped by Move. I was able to
work around it by first running the complete batch file using Move (to
take care of the bulk of the files with the much faster Move), then
making another pass using Copy then Del to pick up the missed files.
Not an ideal solution, but it gets the job done. It does, however,
show that there's something different in the filename handling
capacity of Move and Copy.

Move also seems to have some issues with wildcards. When I do Move
"190*.*", it gets the expected files, but also a handful of files of
the form 196*.*, etc.. I speculate that there's something going on
under the hood with 8.3 filenames. Can anybody here shed any light on
that?

Steve Hendrix
 
Steve said:
I know about the 256 char command line limit, but that does not appear
to be the problem here. The files are all in a single directory whose
name is 8 characters and the directory is at the root level. Filenames
longer than about 128 chars are being skipped by Move. I was able to
work around it by first running the complete batch file using Move (to
take care of the bulk of the files with the much faster Move), then
making another pass using Copy then Del to pick up the missed files.
Not an ideal solution, but it gets the job done. It does, however,
show that there's something different in the filename handling
capacity of Move and Copy.

Move also seems to have some issues with wildcards. When I do Move
"190*.*", it gets the expected files, but also a handful of files of
the form 196*.*, etc.. I speculate that there's something going on
under the hood with 8.3 filenames. Can anybody here shed any light on
that?

Steve Hendrix

I suspect that all your problems are caused by 8.3 issues.
You would need to post some of the file names that you
cannot move, both in LFN and SFN format.
 
I suspect that all your problems are caused by 8.3 issues.
You would need to post some of the file names that you
cannot move, both in LFN and SFN format.

It appears to be so. All the filenames involved start with a date in
the form YYYYMMDD. When I use dir /x to see the generated short
filenames, Windows has kept only the first two characters, followed by
a 4-digit hex number, followed by ~1. Is there a way I can control the
use of 8.3 filenames; i.e., tell Move (or actually the underlying
wildcard matching) to look only at the long filenames?
 
Back
Top