なぜこのファイルを削除しようとしたときに存在しないのですか？

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 foo.c
テスト
^ Z
        1個のファイルがコピーされました。

内容の確認：

S：\>タイプfoo.c
テスト

今、aux .c

S：\> copy con aux.c
^ Z
システムは、指定されたファイルを見つけることができません。
        0個のファイルがコピーされました。

ウィンドウの一部はまだ下位互換性があるようです。

この場合、Hennesが正しく指摘したように、それは明らかにDOS時代から継承された特別な意味についてでしたaux。ただし、将来これにつまずく読者のために、この動作が見られる可能性のある別のケースを追加したいと思います。

これは、末尾にドットが付いたファイルが作成されたときです。さらにエキゾチックなケースもあります。しかしfilename.ext.、そのようなファイル名であり、通常はWin32サブシステムから削除できませんでした。これがKaranからのトリックの出番です。S/彼は、Win32サブシステムの下のレイヤーに渡される前に、その\\?\C:\...形式から「ネイティブ」に変更される名前を使用します（これは、ファイルシステムフィルタードライバーがそれを見る方法でもあります）。形\??\C:\...。これは、Windowsのバージョンに応じて、いわゆるオブジェクトディレクトリ（Sysinternals / MicrosoftのWinObjを使用してオブジェクトマネージャーの名前空間を確認する）またはシンボリックリンク（Vista以降のNTFSの同じ名前のエンティティと混同しないでください）になります。などの別のオブジェクトディレクトリに\DosDevices。後者は単なる名前の1つであり、デフォルトでWin32プロセスに表示されるオブジェクトマネージャ名前空間の一部を示します。詳細については、本シリーズのWindows Internalsを確認するか、特にGoogleのProject Zero （Win32からNTへのパス変換に関する決定的なガイド）でパスの解析を参照してください。特に、Win32ファイルネームスペースとWin32デバイスネームスペースの違いに注意する必要がある場合があります。

では、そもそもそのようなファイルをどのように作成するのでしょうか。いくつかの可能性があります。

1. \\?\X:パス名にプレフィックスを使用して利用可能なパスの長さを260文字から約32767文字（脚注1を参照）に拡張するWin32プログラムは、最初にファイルを作成し、Win32サブシステムのいくつかの制限を回避しました。
2. 別のサブシステムをルートとするプログラム。以前のPOSIXサブシステム（後のInterixは現在SUA）、OS / 2サブシステム（以前は存在していたが、NT 3.51に存在していた）、またはWindowsの意味でのサブシステムではない（Cygwin、私の知る限り）作成されたレイヤーファイルまたはフォルダ。同様に、Windows 10上のWSL（LinuxのWindowsサブシステム）も候補の1つです。
3. 別のオペレーティングシステムで作成された（たとえば、並列Linuxブート）。
4. Windows以外のサーバーにあるネットワーク共有上のファイルです。

最後の2つのポイントは、言及されている対策の1つを示唆しています。Windows以外のライブCDを起動して、ファイルを削除します。

この問題は、古い非Unicode Win32プログラムが複数のコードページのファイル名に直面する場合と実際に比較できます。多くの場合、それぞれのANSIコードページは256文字しか収められないため、それらの一部を「見つける」ことができませんが、UTF-16（ただし、そのサブセットUCS-2ではありません）は、理論上、事実上無制限の量のコードポイントをエンコードできます。 （unicode.orgとWikipediaでこのトピックについて読んでください）。

これが根本的な問題をもう少し理解するのに役立つことを願っています。この長い回答を他の回答のいずれかに編集したくありませんでしたが、補足するだけです。他の答えはこれなしでも完全に有効です。

脚注1：絶対最大（32767文字）に近いパスは、オブジェクトマネージャーとファイルシステムフィルターまたはファイルシステム自体（たとえば、再解析ポイント）の両方によって拡張される可能性があるため、パスの最大文字数は絶対ではありません。 。

私はこの問題を抱えていて、非常にイライラしていました、何もうまくいきませんでした。次に、Linux Ubuntu CDを使用しました。CDROMから起動し、デモモードに移行して、問題のあるファイルが存在する場所にアクセスし、単純にそれらを削除した。それは夢のように機能します。