破損したtarファイルを解凍し、削除できないディレクトリができてしまいました。削除しようとすると、見つからないようですが、ls
は、bashとpython _rm -rf
_で削除しようとした直後を除いて、同様の動作が得られますが、ls
は、見つからないというメッセージを表示し、リストします(_rm -rf
_の後の下記を参照)。 find
コマンドは、ファイルが存在することを示していますが、それでも、ファイルを削除する方法を考えることができません。
これが私の試みです:
ここに、ls
とfind
の両方がディレクトリがあることに同意していることがわかります。
_rl]$ ls
mikeaâ??cnt
rl]$ find -maxdepth 1 -type d -empty -print0
./mikeaâcnt
_
しかし、それを削除することはできません:
_rl]$ find -maxdepth 1 -type d -empty -print0 | xargs -0 rm -f -v
rm: cannot remove `./mikeaâ\302\201\302\204cnt': Is a directory
rl]$ ls
mikeaâ??cnt
_
私はそれにcd
をすることができ、それは空です:
_rl]$ cd mikeaâ^Á^Äcnt/
mikeaâ^Á^Äcnt]$ ls
mikeaâ^Á^Äcnt]$ pwd
.../rl/mikeaâcnt
mikeaâ^Á^Äcnt]$ cd ../
rl]$ ls
mikeaâ??cnt
_
以下は、単純なファイルではなくディレクトリであり、さらにls
が_rm -rf
_の後におかしな動作をすることを確認してください。
_rl]$ rm mikeaâ^Á^Äcnt/
rm: cannot remove `mikeaâ\302\201\302\204cnt/': Is a directory
rl]$ rm -rf mikeaâ^Á^Äcnt/
rl]$ ls
ls: cannot access mikeaâcnt: No such file or directory
mikeaâ??cnt
rl]$
_
したがって、これはpythonでの試行であり、ファイルは見つかりましたが、名前は削除可能な名前として使用できません。
_rl]$ python
Python 2.6.6 (r266:84292, Jul 10 2013, 22:48:45)
[GCC 4.4.7 20120313 (Red Hat 4.4.7-3)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> import shutil
>>> os.listdir('.')
['mikea\xc3\xa2\xc2\x81\xc2\x84cnt']
>>> shutil.rmtree(os.listdir('.')[0] )
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/lib64/python2.6/shutil.py", line 204, in rmtree
onerror(os.listdir, path, sys.exc_info())
File "/usr/lib64/python2.6/shutil.py", line 202, in rmtree
names = os.listdir(path)
OSError: [Errno 2] No such file or directory: 'mikea\xc3\xa2\xc2\x81\xc2\x84cnt'
_
タブ補完を使用しても、取得した名前は使用できません。
_rl]$ rm -rf mikeaâ^Á^Äcnt
rl]$ ls
ls: cannot access mikeaâcnt: No such file or directory
mikeaâ??cnt
_
pythonがbashで示す名前を使用すると、次のようになります。
_rl]$ rm -rf "mikea\xc3\xa2\xc2\x81\xc2\x84cnt"
rl]$ ls
ls: cannot access mikeaâcnt: No such file or directory
mikeaâ??cnt
_
この破損したディレクトリを取り除くために何かできることはありますか?基礎となるファイルシステム(NFS)は機能しているように見え、他の問題は報告されていません。また、tarファイルが壊れるまで、そのような問題はありませんでした。
編集:find
の独自の_-exec
_オプションを使用してrm
を呼び出します
_rl]$ find -maxdepth 1 -type d -empty -exec rm -f {} \;
find: `./mikeaâ\302\201\302\204cnt': No such file or directory
rl]$ ls
ls: cannot access mikeaâcnt: No such file or directory
mikeaâ??cnt
rl]$
_
しかし、ファイルはまだそこにあります(ls
は、ファイルが見つからないというメッセージを出しますが、とにかく表示します)。
2番目の編集:
_rl]$ find -maxdepth 1 -type d -empty -exec rm -rf {} \;
find: `./mikeaâ\302\201\302\204cnt': No such file or directory
rl]$ ls
ls: cannot access mikeaâcnt: No such file or directory
mikeaâ??cnt
_
動作は変わりませんが、ファイルはまだ存在します
3番目の編集:
_rl]$ ls
mikeaâ??cnt
rl]$ find -maxdepth 1 -type d -empty -exec rm -rf {} +
rl]$ ls
ls: cannot access mikeaâcnt: No such file or directory
mikeaâ??cnt
_
python試行_mikeaâcnt
_の出力とこのスクリーンショットを見ると、_mikea\xc3\xa2\xc2\x81\xc2\x84cnt
_以外にも名前があるようです。
4番目の編集:これはワイルドカードを使った試みです:
_rl]$ echo *
mikeaâcnt
rl]$ echo mike*
mikeaâcnt
rl]$ rm -rf mike*
rl]$ ls
ls: cannot access mikeaâcnt: No such file or directory
mikeaâ??cnt
_
そして私のロケール:
_rl]$ locale
LANG=en_US.utf8
LC_CTYPE="en_US.utf8"
LC_NUMERIC="en_US.utf8"
LC_TIME="en_US.utf8"
LC_COLLATE="en_US.utf8"
LC_MONETARY="en_US.utf8"
LC_MESSAGES="en_US.utf8"
LC_PAPER="en_US.utf8"
LC_NAME="en_US.utf8"
LC_ADDRESS="en_US.utf8"
LC_TELEPHONE="en_US.utf8"
LC_MEASUREMENT="en_US.utf8"
LC_IDENTIFICATION="en_US.utf8"
LC_ALL=
_
5番目の編集:
_rl]$ ls -i
ls: cannot access mikeaâcnt: No such file or directory
? mikeaâ??cnt
_
しかし、動作も変更されました。今、ls
とcd
はこれを行います:
_rl]$ ls
ls: cannot access mikeaâcnt: No such file or directory
mikeaâ??cnt
rl]$ cd mikeaâ^Á^Äcnt
mikeaâcnt: No such file or directory.
_
これは削除しようとした後に起こりました、それはvinc17の回答の1つ here で提案されているように、NFSの問題である可能性があると思います。
6番目の編集:これはlsof
と_ls -a
_の出力です
rl] $/usr/sbin/lsofmikeaâ^Á^Äcntlsof:mikeaâ\ xc2\x81\xc2\x84cntでのステータスエラー:そのようなファイルまたはディレクトリはありません
上記は間違っています、ここに正しいlsof
呼び出しがあります:(rlは親ディレクトリです)
_rl]$ /usr/sbin/lsof | grep mike | grep rl
tcsh 11926 mike cwd DIR 0,33 4096 19569249 /home/mike/mish/rl
lsof 14733 mike cwd DIR 0,33 4096 19569249 /home/mike/mish/rl
grep 14734 mike cwd DIR 0,33 4096 19569249 /home/mike/mish/rl
grep 14735 mike cwd DIR 0,33 4096 19569249 /home/mike/mish/rl
lsof 14736 mike cwd DIR 0,33 4096 19569249 /home/mike/mish/rl
rl]$
rl]$ ls -a
ls: cannot access mikeaâcnt: No such file or directory
. .. mikeaâ??cnt
_
7番目の編集:移動は機能しません(この前に試しましたが、出力を保存しませんでした)が、ファイルのls
およびrm
と同じ問題があります。
8番目の編集:これは提案されているように16進文字を使用しています:
_ rl]$ ls --show-control-chars | xxd
0000000: 6d69 6b65 61c3 a2c2 81c2 8463 6e74 0a mikea......cnt.
rl]$ rmdir $'mikea\6d69\6b65\61c3\a2c2\81c2\8463\6e74\0acnt'
rmdir: failed to remove `mikea\006d69\006b651c3\a2c2\\81c2\\8463\006e74': No such file or directory
rl]$ ls
ls: cannot access mikeaâcnt: No such file or directory
mikeaâ??cnt
rl]$
_
9番目の編集:stat
コマンド:
_ rl]$ stat mikeaâ^Á^Äcnt
stat: cannot stat `mikeaâ\302\201\302\204cnt': No such file or directory
rl]$
_
これは、すべての出力からさらに可能性が高いようです。コメントで示唆されているように、バグまたはその他のNFSの誤動作があります。
編集10:これはGistのstrace出力です。これは非常に大きいため、出力または次の2つのコマンドからです。
_strace -xx rmdir ./* | grep -e '-1 E'`
strace -xx -e trace=file ls -li`
_
https://Gist.github.com/mikeatm/e07fa600747a4285e46
編集11:したがって、上記のrmdir
の前に、ディレクトリにcd
を実行できることに気付きましたが、rmdir
の後は、昨日と同様に、再度cd
を実行できませんでした。 _.
_および_..
_ファイルが存在しました:
_rl]$ ls
mikeaâ??cnt
rl]$ cd mikeaâ^Á^Äcnt/
mikeaâ^Á^Äcnt]$ ls
mikeaâ^Á^Äcnt]$ ls -a
. ..
mikeaâ^Á^Äcnt]$ cd ../
_
最終編集:これについてローカル管理者を見つけ、サーバー自体にログオンしてそこから削除することで対処されました。彼らの説明によると、名前の文字セットが不適切であることが問題である可能性があります。
次の このエッセイ からの抜粋は、そのディレクトリの削除を拒否する理由を潜在的に説明しています。
NFSv4では、すべてのファイル名がUTF-8を使用してネットワーク上で交換される必要があります。 NFSv4仕様、RFC 3530は、セクション1.4.3でファイル名をUTF-8でエンコードする必要があると述べています。同じテキストは、新しいNFS 4.1 RFC(RFC 5661)セクション1.7.3にもあります。現在のLinux NFSクライアントは、現在のロケールとUTF-8の間の変換を行わずに、ファイル名をそのまま渡します。 UTF-8以外のファイル名を使用すると、リモートNFSv4システムを使用するシステムで実際の問題になる可能性があります。 NFS仕様に準拠するNFSサーバーは、UTF-8以外のファイル名を拒否することになっています。そのため、LinuxクライアントからNFSサーバーにファイルを実際に保存できるようにする場合は、現在、UTF-8ファイル名を使用する必要があります。つまり、Linuxはファイル名に特定の文字エンコーディングを強制しないと考える人もいますが、実際には、特定のケースではファイル名にUTF-8エンコーディングがすでに必要です。
UTF-8は長期的なアプローチです。システムはUTF-8および多くの古いエンコーディングをサポートする必要があり、UTF-8に切り替える時間を人々に与えます。 「どこでもUTF-8」を使用するには、UTF-8をサポートするようにすべてのツールを更新する必要があります。数年前、これは大きな問題でしたが、2011年の時点でこれは本質的に解決された問題であり、これらのいくつかのトレーリングシステムの軌道は非常に明確であると思います。
すべてのバイトシーケンスが有効なUTF-8であるとは限らず、それらを表示する方法を理解する必要はありません。カーネルがこれらの制限を適用し、UTF-8ファイル名のみが許可されていることを確認している場合、問題はありません...すべてのファイル名は正当なUTF-8になります。 Markus Kuhnのutf8_check C関数は、シーケンスが有効なUTF-8かどうかをすばやく判断できます。
ファイルシステムは、ファイル名が何らかの基準を満たすことを要求する必要があります。人を制御するための邪悪な必要があるからではなく、単に名前を後でいつでも正しく表示できるようにするためです。標準の欠如は、ユーザーにとって物事を難しくし、容易ではありません。しかし、ファイルシステムはファイル名をUTF-8にすることを強制しないため、ゴミが簡単に発生する可能性があります。
このようなファイル/ディレクトリを削除する1つの方法は、inode参照によるものです。
現在のディレクトリ内の要素のiノードを見つけるには:
ls -i
14813568 mikeaâcnt
これを削除するには:
find . -inum 14813568 -delete
コマンドラインで非ASCII文字を使用しないでください。これは、ご覧のとおり、何らかの理由で、ファイル名に必ずしも対応しないためです(Unicodeには、アクセント付き文字を表現するためのさまざまな方法があります)。何かのようなもの:
rm -rf mike*
ファイル名はシェルによって直接生成されるため、機能するはずです。ただし、一致するものが1つだけであることを確認してください(最初にecho mike*
を実行して確認します)。
cd
が機能する場合、問題がファイルシステムレベルで発生する可能性があるため、rm
またはls
がNo such file or directory
と表示する必要がある理由はありません。
注:ls
を使用してディレクトリが空であるかどうかを調べるのではなく、ls -a
を使用してください。
このディレクトリは、別のプロセスで使用されている可能性があります(あるプロセスのcwdである場合も含む)。私見、それがまだ「存在する」理由ですが、エラーが発生する可能性があります。 ls
; lsof
はいくつかの情報を提供しますが、NFSでは、どのマシンがそれを使用しているかを見つける必要があります。特にNFSでは、これにより奇妙なエラーが発生する可能性があります。親ディレクトリのls -a
には、.nfs*
ファイル/ディレクトリが表示される場合があります。
あなたが取得するとき:
$ ls
ls: cannot access mikeaâcnt: No such file or directory
mikeaâ??cnt
ファイルはディレクトリテーブルにまだ存在していると思います。これは、NFSキャッシングが原因であるか、別のプロセスで使用されているためです。ただし、関連情報はありません。 ls
がファイル自体に関する情報を取得しようとすると、ファイル自体が存在しない(ディレクトリテーブルにのみ存在する)ため、エラーが表示され、エラーが表示されます。次に、ls
はディレクトリテーブルにあるため、ファイル名を出力します。 1つの場合に疑問符があるが、他の場合にはないという事実は、ls
IMHO(問題とは無関係)の表示バグが原因です。
find
の-exec
ディレクティブを使用して個人的にテストしました。
$ mkdir -p mikeaâcnt
$ ls
mikeaâcnt
$ find -maxdepth 1 -type d -empty -exec rm -rf {} +
$ ls
$
フォルダーは正しく作成され、正しく削除されました。
@ Igeorget で指摘されているように、GNU find
:
$ find -maxdepth 1 -type d -empty -delete
私もこのコマンドをテストしました、そしてそれは正しく機能します
私も同じ問題を抱えていたと思います。 _☃
_というファイル名で問題を以前に確認しました。この場合のls
はファイルを_â??
_として表示しましたが、_rm ☃
_を使用してファイルを削除することができました。
これにより、次の方法で間違った名前を正しい名前に変換することができました。
まず、ファイル名のバイトを取得します。
_$ ls --show-control-chars | xxd
0000000: 6d69 6b65 61c3 a2c2 81c2 8463 6e74 0a mikea......cnt.
_
次に、これらのバイトをUTF-8としてデコードし、このWebサイトの16進入力を使用して、Unicodeコードポイントを取得します。例: http://software.hixie.ch/utilities/cgi/unicode-decoder/utf8-decoder
_U+006D LATIN SMALL LETTER M character
U+0069 LATIN SMALL LETTER I character
U+006B LATIN SMALL LETTER K character
U+0065 LATIN SMALL LETTER E character
U+0061 LATIN SMALL LETTER A character
U+00E2 LATIN SMALL LETTER A WITH CIRCUMFLEX character (â)
U+0081 <control> character ()
U+0084 <control> character („)
U+0063 LATIN SMALL LETTER C character
U+006E LATIN SMALL LETTER N character
U+0074 LATIN SMALL LETTER T character
_
これらはすべてバイト境界の下にあることに注意してください。次のバイトを取得します。
_6D 69 6B 65 61 E2 81 84 63 6E 74
_
このシーケンスをUTF-8で処理すると、次のようになります。
_U+006D LATIN SMALL LETTER M character
U+0069 LATIN SMALL LETTER I character
U+006B LATIN SMALL LETTER K character
U+0065 LATIN SMALL LETTER E character
U+0061 LATIN SMALL LETTER A character
U+2044 FRACTION SLASH character (⁄)
U+0063 LATIN SMALL LETTER C character
U+006E LATIN SMALL LETTER N character
U+0074 LATIN SMALL LETTER T character
_
したがって、ファイル名は_mikea⁄cnt
_で、通常のフォワードスラッシュの代わりにフラクションスラッシュを使用します。この名前をrmdir
に渡すことができます。
rm -rf ./mikeaâcnt
またはrm -rf "./mikeaâcnt"
または絶対パスを使用してみましたか?また、rm
の代わりにrmdir ./mikeaâcnt
を試してください。
stat
でそのファイルのiノードを取得しようとしましたか?
stat mike*
これにより、iノード番号(およびその他のデータ)が表示され、それを削除してみることができます。
同様の問題がありました。 Gnome、KDE、または何らかのXwindow DMをお持ちですか?ファイルブロザーを開いて、そこからファイルを削除した場合。
うまくいくはずです。
コマンドラインからの解決策を見たいのですが、私の場合、コマンドラインからそれを削除する方法を理解しようとして多くの時間を失った後、nautilusまたは他のファイルを削除するのと同じくらい簡単であることがわかりました他のファイルエクスプローラー(真実は、私がnautilusでのみ試したことです)。
ファイル/フォルダー名の正しい16進コードを取得した後(適切と思われる方法を使用して、ls --show-control-chars | xxd
)、bashで実行する場合、このような文字をアドレス指定するには、いくつかの特別な構成を使用する必要があります。
rmdir $'mikea\xc3\xa2\xc2\x81\xc2\x84cnt'
それ以外の場合、バックスラッシュはバニラのバックスラッシュとして扱われます。