在Windows上使用文件名回車處理文件

Question

我有一個外部USB，NTFS格式的硬盤驅動器，其中包含許多文件，我需要最終復制到Windows Server 2008 R2計算機上的驅動器。

驅動器上的文件由安裝在Solaris上的驅動器運行的腳本放置在那里。 執行此副本的用戶不小心並在Windows計算機上編輯了他們的副本腳本，從而產生了shell腳本行，例如：

cp /sourceDir/sourceFileName /externalDrivePath/targetFileName\r\n

因此，外部驅動器上的文件在其文件名中有一個尾隨回車符。 標准Windows復制實用程序（copy，xcopy，robocopy）無法復制這些文件，錯誤為0x7B / 123：“文件名，目錄名稱或卷標語法不正確。”

我已經測試過，並且相當確定如果我將驅動器再次安裝在Linux機器上，我應該可以使用以下命令修復文件：

mv /externalDrive/targetFileName\r /externalDrivePath/targetFileName\n

但是，我沒有立即訪問Linux機器。

到目前為止我已經嘗試過修復/移動這些文件：

Windows Server 2008 R2上的“應用程序”解決方案：

1. 在Windows資源管理器中重命名文件 - 由於文件數量龐大，這將是不可行的解決方案，但它無論如何都無法正常工作。
2. 與cmd提示符下的文件名匹配的通配符模式，例如copy E:\\externalDrivePath\\targetFileName* anotherPath 。 失敗，出現0x7B錯誤。
3. 使用8.3（短）文件名從cmd提示符復制文件。 有問題的文件沒有短名稱，每個輸出dir /x

Windows Server 2008 R2上的“編程”解決方案：

1. 使用Python / Java復制/重命名文件：任何打開/復制回車文件的嘗試都會將異常跟蹤引發回同一個0x7B Windows錯誤。
2. 使用Windows C'CopyFile'API復制文件：失敗，出現0x7B錯誤。 在這里，我使用FindNextFile API找到了這些文件，並將該源路徑傳遞給CopyFile，但操作系統仍無法復制該文件。
3. 使用fopen，ofstream等在C語言中編寫我自己的文件復制功能.fopen調用再次因0x7B而失敗。
4. 使用C ++ boost :: filesystem API復制文件：失敗，出現0x7B錯誤。 再次，使用boost :: filesystem :: directory_iterator找到文件，並將找到的文件的路徑傳遞給boost :: filesystem :: copy_file（）
5. 將Win32 API CopyFile / MoveFile的文件路徑提供為“\\？\\ E：\\ externalDrivePath \\ targetFileName \\ r \\ n”。 調用再次失敗，出現0x7B錯誤。

我還涉及在OS X機器上安裝此驅動器以運行副本，期望它將像Solaris那樣為NTFS驅動器提供支持。 但是，它無法將類似的錯誤消息復制到Windows - 我猜OS X的NTFS實現更像“Windows-like”？

如果這在Windows上是可解的，我覺得它要么需要一個非常低級的C函數來操作FILE本身，而不是根據它的字符串文件名“打開”它。 不知道該怎么做。 那個，或者我不知道的一些文件修復工具已經包含了這個功能。

任何替代方法或建議如何實現我所描述的將是最受歡迎的。

Answer 1

TLDR：嘗試使用前綴為\\\\?\\並包含尾隨回車符的unicode路徑的CreateFileW 。

\\\\?\\ path語法繞過了許多常用的驗證規則，unicode擴展等，並允許長文件路徑，甚至（危險地）允許文件名中的斜杠等字符。

鑒於此，我認為回車應該是相當微不足道的...

這個與長文件名相關的頁面有更多細節。 相關部分引用如下

無需對路徑和文件名字符串執行任何Unicode規范化以供Windows文件I / O API函數使用，因為文件系統將路徑和文件名視為不透明的WCHAR序列。 在對相關Windows文件I / O API函數進行任何調用之外，應記住應用程序所需的任何規范化。

使用API​​創建目錄時，指定的路徑不能太長，以至於無法附加8.3文件名（即目錄名不能超過MAX_PATH減去12）。 shell和文件系統有不同的要求。 可以使用Windows API創建一個shell用戶界面無法正確解釋的路徑。

從這里開始

在較新的文件系統（如NTFS，ex-FAT，UDFS和FAT32）上，Windows以Unicode格式將長文件名存儲在磁盤上，這意味着始終保留原始長文件名。 即使長文件名包含擴展字符，也不管在磁盤讀取或寫入操作期間處於活動狀態的代碼頁，都是如此。 即使文件系統不區分大小寫，也會保留文件名的大小寫...

Answer 2

在Windows 3.11上，我在90年代中期遇到過類似的問題。

我最終使用了C程序的rename （在<stdio.h>聲明）。

如果失敗，您可以嘗試低級C系統調用： open ， read和write將文件復制到新名稱。

低級別呼叫通常會繞過用戶友好的高級功能所施加的限制。