1か月ほど前、CygwinのフォルダーにあるLinuxソースの風袋引きを解除しました(Linuxを実行している他のコンピューターが遅いシングルコアSempronであるため、MinGWでコンパイルできるかどうか知りたいと思いました)。削除してみましたが、ファイルが1つ残っているので削除されません...
CygwinはC:\cygwin
にあり、ソースをC:\cygwin\src\linux-3.7.1
で解凍しました。コンパイルされませんでした...そこでフォルダを削除してみました。すべてのファイルが削除されているわけではないことに気付くまで、順調に進んでいました。 linux-3.7.1
フォルダーをもう一度削除しようとすると、エラーが表示されました。
フォルダを開いたところ、ソースファイルが1つ残っていることがわかりました:aux.c
、これはC:\cygwin\src\linux-3.7.1\drivers\gpu\drm\nouveau\core\subdev\i2c\aux.c
にあります。
ならない:
一般的なプロパティ:
セキュリティプロパティ:
このファイルを削除するにはどうすればよいですか?
(昇格された)コマンドプロンプトからこれを試してください:
del \\?\C:\cygwin\src\linux-3.7.1\drivers\gpu\drm\nouveau\core\subdev\i2c\aux.c
あなたが遭遇した問題は、古代のDOS予約によるものです。
以下のリストのファイルには特別な意味があります。その一部は、現代のWindowsバージョンにもまだ存在しています。
CON、PRN、[〜#〜] aux [〜#〜]、CLOCK $、NUL、COM1、COM2、COM3、COM4、COM5、COM6、COM7、COM8、COM9 LPT1、LPT2、LPT3 、LPT4、LPT5、LPT6、LPT7、LPT8、およびLPT9。
それらを削除する最も簡単な方法は、これらのファイル名を特別なものとして扱わないオペレーティングシステムを起動することです。 (例:Windows以外のliveCDを起動します)。
[編集] win7-x86 Ultimateで行われたテスト:
簡単なテストファイルの作成:
S:\> copy con foo.c test ^ Z 1つのファイルがコピーされました。
内容の確認:
S:\> type foo.c test
今aux。c
S:\> copy con aux.c ^ Z 指定されたファイルが見つかりません。 0個のファイルがコピーされました。
Windowsの一部はまだ下位互換性があるようです。
この場合、 Hennes が正しく指摘しているように、それは明らかに DOS時代から継承されたaux
の特別な意味 に関するものでした。ただし、将来これに遭遇する読者のために、この動作が見られる可能性のある別のケースを追加したいと思います。
それは、ファイルが末尾のドットで作成されたときです。もっとエキゾチックなケースもあります。ただし、filename.ext.
はそのようなファイル名であり、通常はWin32サブシステムから削除できませんでした。ここで、 Karan のトリックが登場します。S/彼は、Win32サブシステムの下のレイヤーに渡される前に、その\\?\C:\...
形式から「ネイティブ」に変更される名前を使用します。 (これは、ファイルシステムフィルタードライバーがそれを認識する方法でもあります)form \??\C:\...
。 Windowsのバージョンに応じて、これはいわゆるオブジェクトディレクトリ(Sysinternals/MicrosoftのWinObjを使用してオブジェクトマネージャの名前空間を確認)またはシンボリックリンク(Vista以降のNTFSで同じ名前のエンティティと混同しないでください)になります。 \DosDevices
などの別のオブジェクトディレクトリに移動します。後者は単なる1つの名前であり、デフォルトでWin32プロセスに表示されるオブジェクトマネージャ名前空間の一部を説明します。詳細については、本シリーズWindows Internalsを確認するか、特にGoogleのProject Zeroでパス解析について読んでください (Win32からNTへのパス変換に関する決定的なガイド) 。特に、Win32ファイルの名前空間とWin32デバイスの名前空間の違いに注意を払うことをお勧めします。
では、そもそもそのようなファイルをどのように作成できるのでしょうか。いくつかの可能性があります。
\\?\X:
プレフィックスを使用するWin32プログラム(脚注1を参照)は、最初にファイルを作成し、回避しましたWin32サブシステムのいくつかの制限。最後の2つのポイントは、前述の解決策の1つを示唆しています。Windows以外のライブCDを起動し、ファイルを削除します。
この問題は、実際には、古い非UnicodeWin32プログラムが複数のコードページからのファイル名に直面している場合と比較できます。多くの場合、それらの一部を「見つける」ことができません。これは、それぞれのANSIコードページが256文字しか収まらないのに対し、UTF-16(ただしサブセットUCS-2ではない)は理論上、事実上無制限の量のコードポイントをエンコードできるためです。 (このトピックについては、 nicode.org および Wikipedia で読んでください)。
これが根本的な問題をもう少し理解するのに役立つことを願っています。この長い回答を他の回答の1つに編集したくありませんでしたが、onlyはそれらを補完します。他の答えはこれがなくても完全に有効です。
脚注1:絶対最大値(32767文字)に近いパスはオブジェクトマネージャーとオブジェクトマネージャーの両方によって拡張される可能性があるため、パス内の最大文字数は絶対値ではありませんファイルシステムフィルターまたはファイルシステム自体(再解析ポイントなど)。
私はこの問題を抱えていて、非常にイライラしました。何も機能しませんでした。次に、Linux UbuntuCDを使用しました。 CDROMから起動し、デモモードに移行し、問題のあるファイルがある場所にアクセスして、単に削除しました。それは夢のように機能します。