ディレクトリは内部的にリストできず、外部からのみリストされます。

私はcross-gccを構築する3つのサブフォルダがあるディレクトリを持っています。だからディレクトリがありますbinutils。gccこれはglibcビルドディレクトリにすぎず、そのソースは別のディレクトリにあります。すべてがうまくいった。すべてをコンパイルし、カスタムパスにインストールしました。

（マイビルドツリーの）サブディレクトリに移動しようとすると、glibc内容を一覧表示できず、読み取れないいくつかのエラーメッセージが表示されます。

$ ls
ls: �����: ��dJ: Error 1673445588re

この操作をやり直すと、別のエラー番号が表示されます。

$ ls
ls: �vP��: ��u: Error 3137748

または特定のファイル：

 $ ls config.status
 ls: : ���s: Error 123785428

上記の階層の内容を一覧表示すると、次のように動作します。

 $ ls glibc
 Makefile        catgets                   ctype       gnu        
 ld.map               libc.so.6         libmvec.map
 ...

ルートになってそのディレクトリに移動すると、次のようにリストすることもできます。

 # ls 
 Makefile        catgets                   ctype       gnu        
 ld.map               libc.so.6         libmvec.map
 ...

フォルダ自体：

 $ ls -lh glibc -d
 drwxr-xr-x 63 david david 4.0K 17. Aug 16:30 glibc

正しい所有者、正しい権限。

私は逃げた

  # e2fsck -pfc /dev/sdb4

お金を守ってください。

ログファイルにエラーはなく、dmesgエラーも表示されず、ファイルシステムチェックでもエラーは報告されません。これは一体何ですか？

修正する

gccを介して構築するという事実により、私の環境はこれらのライブラリやバイナリの影響を受けます。クロスコンパイルまたはcross-gccのビルド中に環境を構築するために使用されるシェルのパスを調整し、それをcross-gccのインストールパスとして指定しました。しかし、gccはそのような機能を提供せず、/bin/ls私のLD_LIBRARY_PATH設定もありません。このlsコマンドは私のシステムから来ます。

$ where ls
ls: aliased to ls --color=always
/bin/ls
$ ldd /bin/ls
linux-vdso.so.1 (0x00007ffea1362000)
libc.so.6 => /lib64/libc.so.6 (0x00007fc18b429000)
/lib64/ld-linux-x86-64.so.2 (0x00007fc18b7c2000)

他のすべてはうまくいくようです。私のシステムやこのSSD（Samsung SSD 840 EVO 500GB、EXT0DB6Q）には他の問題はありません。何度も再起動しても問題は解決しません。

私がこれまで気付いていなかったのは、このディレクトリにあると、すべてのlsコマンドが失敗し、もはやホームディレクトリを一覧表示できないことです。

$ ls ~
ls: ���e�: �i"�5: Error 18446744071861719252

毎回異なる出力：

$ ls ~
ls: Pg��: ��{
: Error 2070020308

~/cross-build/inc100/glibc # this is the path to this directory
$ echo $PATH
/usr/local/bin:/usr/bin:/bin:/opt/bin:/usr/x86_64-pc-linux-gnu/gcc-
bin/5.4.0:/usr/x86_64-pc-linux-gnu/i686-pc-linux-gnu/gcc-
bin/6.4.0:/home/david/usr/bin

まあ：

~/cross-build/inc100/
$ ls glibc
.... libc.so libc.so.6

ファイルを上記のディレクトリのいずれかに移動し、そのディレクトリに移動すると機能しますlibc.so。libc.so.backup

リンカがこのディレクトリでlibc.soを見つけて単に使用するようです。しかし、なぜechoは動作しますが、lsは動作しませんか？find間違っています。この動作を防ぐにはどうすればよいですか？

修正する echoこれはシェル内蔵lsなどがfindバイナリに接続されているため動作するためlibc.so動作が異なります。

私はなぜこのようなことが起こるのか、どうすれば回避できるのかわかりません。私はこれらの「ウィンドウモード」の動作を本当に望んでいません。