특정 유형의 의사 파일(예: procfs 및 sysfs 가상 파일 시스템의 많은 의사 파일)은 파일 크기가 없으며( statreturn == 0) 지원 되지 st_size않습니다 . 일반 무작위 액세스 파일보다 FIFO. 불행히도 그들은 파일 유형에 대해서도 거짓말을 했습니다. 그들의 필드에는 비트가 포함되어 있습니다 . 이는 비트 가 아닌 일반 파일을 의미합니다 .SEEK_ENDfseek/proc/cpuinfost_modeS_IFREGS_IFIFO
이로 인해 데이터를 "더 스마트하게" 관리하려는 입력 코드에 문제가 발생하고 /proc/*파일을 볼 때 도구가 중단된다는 보고가 많이 있습니다.
저는 사용자가 지정한 다양한 소스에서 스트림을 가져올 수 있는 일반 스트림 입력 시스템을 갖춘 이러한 도구 중 하나를 개발 중입니다. 또한 순차 "순차적" 파이프 및 소켓과 같은 비무작위 액세스 스트림을 처리할 수 있으며 이에 사용되는 동일한 기술이 procfs/sysfs/기타 가상 파일 시스템 개체에 대해 작동합니다. 하나를 보면.
FILE 포인터, 파일 설명자 또는 파일 경로 이름이 주어지면 C에서 이러한 문제가 있는 의사 파일 개체 중 하나를 보고 있는지 여부를 어떻게 판단할 수 있습니까? (참고: 파일 시스템을 임의로 마운트할 수 있기 때문에 /proc로 시작하는 경로를 확인하는 것만으로는 충분하지 않습니다. 파일의 st_size합계를 신뢰할 수 있는지 알려주는 OS가 필요합니다 SEEK_END.) 현대에 합리적으로 이식 가능한 솔루션이 있습니까? *아니야?
(이것은 프로그래밍에 관한 질문입니다. 필요한 경우 자유롭게 SO로 옮기십시오.)
답변1
파일 설명자를 사용하고 보고된 결과 크기가 0 인 stat경우 파일이 비어 있거나 크기를 알 수 없는 것입니다. 파일이 비어 있으면 게임을 플레이할 때 파일을 더 효율적으로 읽는 데 별 의미가 없습니다.
따라서 크기를 알 수 없는 경우 대체 코드 경로를 사용해야 하며 파일이 비어 있어도 문제가 되지 않습니다.
파일 이름만으로 파일 형식을 진단하는 것은 미끼 및 전환 공격(또는 버그)에 노출될 수 있으므로 주의해야 합니다. 파일을 성공적으로 열 때까지 아무것도 찾으려고 시도해서는 안 되며, 이름이 더 이상 파일과 연결되지 않을 수 있으므로 이름이 아닌 파일 설명자를 직간접적으로 사용해야 합니다. 같은 파일.
도움이 되길 바랍니다.
답변2
경로를 확인하는 것은 두 번째 좋은 생각일 뿐입니다. 대신 파일 시스템(장치)을 확인할 수 있습니다 st_dev=makedev(0, 14). 메이저 번호가 0이면 proc, sys등 입니다.
커널조차도 파일의 성격을 결정할 수 없습니다. .kernel 을 사용하여 일반 파일 시스템을 가정하는 FUSE 마운트를 상상해 보세요. /proc의사 파일 시스템에는 피하고 싶은 문제가 있습니다.
SEEK_END하지만 이것이 작동하지 않는다는 것을 안다면 테스트에 사용해 보는 것은 어떨까요?