title: Handling files with carriage return in filename on Windows
body: <p>I have an external USB, NTFS-formatted hard drive which contains many files which I need to eventually copy to a drive on a Windows Server 2008 R2 machine.</p>
  
  <p>The files on the drive were placed there by scripts run with the drive mounted on Solaris. The user who did this copy was careless and edited their copy script on a Windows machine, resulting in shell script lines such as:</p>
  
  <pre><code>cp /sourceDir/sourceFileName /externalDrivePath/targetFileName\r\n
  </code></pre>
  
  <p>and as such, the files on the external drive have a trailing carriage return in their filenames. Standard Windows copy utilities (copy, xcopy, robocopy) fail to copy these files with error 0x7B / 123 : "The filename, directory name, or volume label syntax is incorrect." </p>
  
  <p>I have tested, and am fairly sure that if I had the drive mounted again on a Linux box, I should be able to repair the files with commands such as:</p>
  
  <pre><code>mv /externalDrive/targetFileName\r /externalDrivePath/targetFileName\n
  </code></pre>
  
  <p>However, I do not have immediate access to a Linux machine.</p>
  
  <p>What I have tried so far to repair/move these files:</p>
  
  <p>"Application" solutions on Windows Server 2008 R2:</p>
  
  <ol>
  <li>Renaming files in Windows Explorer -- would be unfeasible solution due to sheer volume of files, but it doesn't work anyways.</li>
  <li>Wildcard pattern matching the filenames from cmd prompt, e.g. <code>copy E:\externalDrivePath\targetFileName* anotherPath</code>. Fails with 0x7B error.</li>
  <li>Copying files from cmd prompt using 8.3 (short) filenames. Files in question do not have short names, per output of <code>dir /x</code></li>
  </ol>
  
  <p>"Programming" solutions on Windows Server 2008 R2:</p>
  
  <ol>
  <li>Copying/Renaming files using Python/Java: any attempt to open/copy the carriage-return file throws exception tracing back to the same 0x7B Windows error.</li>
  <li>Copying files using Windows C 'CopyFile' API: fails with 0x7B error. Here I found the files using FindNextFile API, and passed that source path into CopyFile, but the OS still fails to copy the file.</li>
  <li>Writing my own file copy function in C using fopen, ofstream, etc. The fopen call again fails with 0x7B.</li>
  <li>Copying files using C++ boost::filesystem APIs: fails with 0x7B error. Again, found the files using a boost::filesystem::directory_iterator and passed the found file's path to boost::filesystem::copy_file()</li>
  <li>Providing file path to Win32 APIs CopyFile / MoveFile as "\?\E:\externalDrivePath\targetFileName\r". Calls fail again with 0x7B error.</li>
  </ol>
  
  <p>I also dabbled with mounting this drive on an OS X machine to run the copy, expecting it would provide support for the NTFS drive more like Solaris did. However, it fails to copy with similar error messages to Windows -- I guess OS X's NTFS implementation is more "Windows-like"?</p>
  
  <p>If this is solvable on Windows, I feel like it's going to either require a very low-level C function that manipulates the FILE itself, without 'opening' it based on its string filename. Not sure how to go about that. That, or some file repair utility that I'm unaware of which incorporates this functionality already.</p>
  
  <p>Any alternative approaches or suggestions how to implement what I'm describing would be most appreciated.</p>