디렉토리는 내부적으로 나열될 수 없으며 외부에서만 나열됩니다.

나는 cross-gcc를 빌드하는 세 개의 하위 폴더가 있는 디렉토리를 가지고 있습니다. 그래서 디렉터리가 있습니다 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(삼성 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하므로 동작이 다릅니다.

나는 아직도 이런 일이 왜 발생하는지, 어떻게 피할 수 있는지 알지 못합니다. 저는 이러한 "창 모드" 동작을 정말로 원하지 않습니다.