Wildcard XCOPY operations interrupted when quotes are present in filenames

[Lewis Rosenthal]

Command line under 4OS2 3.08 & result:

[j:\images] xcopy g:\temp\*.pdf .

Source files are being read...

SYS1186: XCOPY cannot access the source file.
Source files are being read...

SYS1186: XCOPY cannot access the source file.
Source files are being read...

SYS1186: XCOPY cannot access the source file.
Source files are being read...

G:\temp\Federal 941 3Q 2012 Employer's Quarterly Federal Tax Return.pdf

1 file(s) copied.

Run under CMD:

[J:\images]xcopy g:\temp\*.pdf .

Source files are being read...

G:\temp\Federal 941 3Q 2012 Employer's Quarterly Federal Tax Return.pdf
G:\temp\Virginia VA-5 2012-09 Employer's Return of Income Tax Withheld.pdf
G:\temp\Virginia VEC-FC-20 3Q 2012 Employer's Quarterly Tax Report.pdf
G:\temp\Virginia VEC-FC-21 3Q 2012 Employer's Quarterly Payroll Report.pdf

4 file(s) copied.

Command line under 4OS2 2.08 (again), with quotes around the wildcard spec:

[j:\images] xcopy "g:\temp\*.pdf" .

Source files are being read...

G:\temp\Federal 941 3Q 2012 Employer's Quarterly Federal Tax Return.pdf
G:\temp\Virginia VA-5 2012-09 Employer's Return of Income Tax Withheld.pdf
G:\temp\Virginia VEC-FC-20 3Q 2012 Employer's Quarterly Tax Report.pdf
G:\temp\Virginia VEC-FC-21 3Q 2012 Employer's Quarterly Payroll Report.pdf

4 file(s) copied.

(COPY works as expected with the wildcard and no quotes, successfully transferring each file.)

Unfortunately, it's not always possible to know when one may encounter stray quotes in filenames, particularly when files have been created on other platforms or by people who are not aware of the implications of such things on the command line. This means that until/unless this issue is addressed, it is always necessary to surround wildcard paths in quotations or use COPY instead of XCOPY (not sure offhand what other commands might be impacted by this).

[Lewis Rosenthal]

Other odd behavior with wildcards possibly related:

[j:\images] del g:\temp\*.pdf .
Deleting G:\temp\Federal 941 3Q 2012 Employer's Quarterly Federal Tax Return.pdf

Deleting G:\temp\Virginia VA-5 2012-09 Employer's Return of Income Tax Withheld.
pdf
Deleting G:\temp\Virginia VEC-FC-20 3Q 2012 Employer's Quarterly Tax Report.pdf
Deleting G:\temp\Virginia VEC-FC-21 3Q 2012 Employer's Quarterly Payroll Report.
pdf
J:\Images\va\Docs\Vienna\2012\* : Are you sure (Y/N)? N
     4 files deleted

Not sure why the "*" was processed separately following *.pdf.

[Steven Levine]

Hi Lewis,

I very much doubt this is a 4OS2 issue. I cannot replicate the behavior you describe here. Perhaps you have defined an xcopy alias?

Without something that causes 4OS2 to invoke something other than xcopy.exe, the parameters are passed unsullied to xcopy.exe.

[Lewis Rosenthal]

Interesting.

No, I have no alias assigned for xcopy. Thinking further...

The above operations were against a Samba share. I'll test locally with those same files and see what I get.

[Lewis Rosenthal]

Nope. Must have been something which corrupted my environment (low shared memory? been seeing that a lot lately, to the point of not being able to save ini files at shutdown). I just tested again, with dummy files created with the same names, xcopy from local directory to local directory, xcopy local directory to Samba share, and xcopy Samba share back to another local directory all work without complaint.

Let's close this as invalid. Sorry for the red herring!

[Lewis Rosenthal]

PS - I tested against the exact same Samba share.

[Lewis Rosenthal]

This turned out to be a Novell problem on the NSS volume. Other weird things started happening on the same volume (inability to save long filenames, among other things). A pool verify came up clean (nss /poolverify), and a subsequent restart of the server and a dsrepair pass to tighten up the directory service database (only 1 minor error), seemed to resolve the entire problem. So, this was just the first observed symptom of something else entirely. :-)