Fixed copy from share error

[TimButterfield]

I copied some Visual Studio C# build output files from a share and experienced copy errors with some of the files.

copy \\computer_name\share_name . /s
1,422 files copied 101 failed

The files with the error had a prefix added to the path resulting in the error.

\\?\\\computer_name\share_name\dir1\filename.ext => D:\dest_folder\build_num\dir1\filename.ext

TCC: (Sys) The filename, directory name, or volume label syntax is incorrect.

Here is the distribution of C# build output file types that had that problem:

• exe: 4
• pdb: 17
• dll: 74
• config: 6

Here are the totals for the files on that share:

Total for: \\computer_name\share_name\*
669,800,184 bytes in 1,523 files and 1,124 dirs 672,845,824 bytes allocated

This error was experienced in TCMD and TCC/LE.

TCC 13.03.47 Windows 7 [Version 6.1.7600]
TCC Build 47 Windows 7 Build 7600

TCC LE 13.03.45 Windows 2003 [Version 5.2.3790]
TCC LE Build 45 Windows 2003 Build 3790 Service Pack 2

When I copied from the share using Windows Explorer, there were no errors.

 

[rconn]

Were any of the pathnames + filenames > 248 characters?

 

[JohnQSmith]

Were any of the pathnames + filenames > 248 characters?

Is that a limitation?

 

[TimButterfield]

Were any of the pathnames + filenames > 248 characters?

Yes. Max len was 259.

 

[rconn]

Is that a limitation?

Not a limitation, but longer filenames have to have a "\\?\UNC" prefixed or Windows will reject the name.

 

[Steve Fabian]

Could TCMD do this automatically when required?

 

[TimButterfield]

Could TCMD do this automatically when required?

In my error output, this prefix has already been added. But, it still failed to copy.

 

[Charles Dye]

Should the \\?\ really be prepended when the filename is already in UNC format?

 

[rconn]

Could TCMD do this automatically when required?

It already does.

 

[rconn]

In my error output, this prefix has already been added. But, it still failed to copy.

TCC will prefix "\\?\UNC" if a sharename is too long for the Windows APIs. But something (either somewhere else in TCC, some other app, or Windows) is prefixing the incorrect "\\?\" string instead (which should only be added to pathnames with a drive spec).

 

[Steve Fabian]

It already does.

As is the case so often, it's too late to ask Rex to do something - he has already done it. Thanks!