View Single Post
  #6  
Old July 28th 04, 08:18 PM
Peter Poulimenakos
external usenet poster
 
Posts: n/a
Default xcopy32 problem with spaces in file name


-----Original Message-----
On Mon, 26 Jul 2004 07:16:49 -0700, "Peter Poulimenakos"
put finger to keyboard and composed:


-----Original Message-----
On Thu, 22 Jul 2004 13:04:42 -0700, "Peter=20

Poulimenakos"
put finger to keyboard and composed:

I am receiving the following error when I try to use=20

the=20
xcopy32 command to copy files to a network drive:

'The system cannot find the file specified.'

Now the files it's having a problem with all have a=20

space=20
before the filename. ex: " Combined Invoice_NAFTA=20
Cert.dbf" when I view them in explorer. But when=20

Xcopy32=20
tries to copy the above mentioned file it shows the=20

file=20
its trying to copy as "_Combined Invoice_NAFTA=20
Cert.dbf"... And hence can't find the file.

Is there a way to correct this behavior?

The first character in the filename is not a space. To=20

see what it
really is, drop into a DOS window and execute the=20

following:

dir *.dbf /b dirlist
debug DIRLIST
-d 100
-d
...
-q

or

dir *.dbf /b dirlist
edit /64 dirlist

Move the cursor over the hidden character and check=20

its=20
decimal ASCII
"value" at the bottom of the screen.

How are you invoking the Xcopy/Xcopy32 command, ie=20

what=20
is the exact
syntax? FYI, in a Win DOS box, the Xcopy command=20

automatically invokes
Xcopy32.

FWIW, I have no trouble creating a filename with a=20

leading space and
then using Xcopy (or Xcopy32) to make a copy of it.=20

The=20
following
commands work as expected in a Windows DOS box.

rem " junk1" ------ creates a zero byte file
xcopy " junk1" " junk2"


- Franc Zabkar
--=20
Please remove one 's' from my address when replying by=20

email.
.



Hi Guy and thanks for the replies,

I havent had a chance to try out your DOS command (dir=20
*.dbf /b dirlist) just yet, ...


This procedure takes about one minute and may help=20

explain why your
two PCs behave differently. At the very least, if we=20

knew the byte
value(s) of the leading character(s) we may at least be=20

able to
reproduce your problem on our machines.

but below is the command=20
I'm using to copy the files:

xcopy32 c:\fedext~1\*.* z:\fedex_trade /a/d/s/y

I've also used the /k/c witches without any success as=20
well... I've used this command on several 98se PCs with=20
success copying files with 'spaces' at the begining of=20
the file name, it's just this one PC that is giving me=20
trouble (98se as well).

Below is a DOS level directory dump comparison between=20
two PCs where the files copied successfully and my=20
problem PC.

Good PC: (as in the 'spaced' files will copy)
Volume in drive C is WIN98-2 =20
Volume Serial Number is 0675-17E7
Directory of C:\FedEx Trade Networks Forms


HELP-N~1 FOF 50,228 25/07/02 18:25 Help-NAFTA=20
Certificate.fof


=FFCOMBI~1 DBF 13,914 29/01/03 10:11 =FFCombined=20
Invoice_NAFTA Cert.dbf



Problem PC: (as in the 'spaced' files will not copy)
Volume in drive C has no label
Volume Serial Number is 6D59-1A1C
Directory of C:\FedEx Trade Networks Forms


HELP-N~1 FOF 50,228 07-25-02 6:25p Help-NAFTA=20
Certificate.fof


_COMBI~1 DBF 13,914 01-29-03 10:11a _Combined=20
Invoice_NAFTA Cert.dbf


I notice that the two PCs use different date and time=20

formats. Could
this be significant?

Are the filenames generated by the software, or are they=20

created
manually? My newsreader sees the leading character in=20

the first dir
listing as a lower case y with an "umlaut", whereas the=20

leading
character in the second listing is an underscore. The=20

fact that these
two characters are different is puzzling. Did you=20

transcribe either
listing by hand, or did the same software generate two=20

different
leading characters? In any case, I'm puzzled why there=20

should there be
any non-ASCII leading characters at all.

This may be a red herring, but the ALT 0255 combination=20

(numeric
keypad) displays the aforementioned lower case y when=20

executed in a
Windows app such as Wordpad, while ALT 255 produces an=20

ASCII
underscore (=3D ALT 095).


Hi Frank,

I hadn't noticed the date time format was different...=20
Strange if you ask me seeing as both systems are 98se.=20
Perhaps one was upgraded from Windows 95 or something=20
like that.=20

Anyways to answer your question, these file names where=20
generated by a software install (FedEx trade software). I=20
just wanted to automatically backup the directory to=20
another location for backup purposes. No the directory=20
listing was not transcribed by hand. I just dumped the=20
directory listing to a text file on both PCs and cut and=20
past the results to this newsgroup using the following=20
DOS cmd:

dir c:\text.txt

I was looking for some sort of registry or ini file fix=20
to resolve this behavior... But it don't look like I'm=20
gonna get it :-)...=20

Quick question though, I was trying the various ALT xxx=20
combinations, all work as you described except for the=20
ALT 255... In my case it doesn't produce a=20
underscore '_', but rather a space ' '. Is this correct?

Regards,

Peter Poulimenakos