파일 매니저에서 확장명(.xxx)으로 파일을 판단하는 문제.

파일을 어떻게 읽는지는 설정에 따라 다른 걸로 기억합니다만 .. 어디서 바꾸는지는 기억이 안납니다..

그건 그렇고...

저는 시스템이 확장자와는 상관없이 판단해서 어떤 파일인지 알아서 보여주는 게 좋다고 봅니다. 물론, 설정에 따라서는 그런 기능을 꺼도 별 문제는 없겠지요.

사실 확장자라는 게, 도스시절에 파일이름 8.3 의 제한때문에 확정된 거라고 해도 큰 무리는 없으니까요.

우선은 확장자를 이용해서 판단하고 포커스가 맞춰졌을 때 mime magic 을 통해서 어떤 파일인지를 판단하지 않나요 ;)

노틸러스는 그렇게 동작했던거 같은데요

제목은 얏옹인데 실제로는 동물의 왕국이나 시스터 액트인 경우는 어떻게 판별할까요?

grep -i "skincolor" 얏옹

헉...오픈오피스를 깔았더니 더블클릭에 writer 가 열리네요-_-;;;
오랜 옛날에는 gvim-vfs 라고 제가 스크립트 만들어 놓은것을
다른프로그램으로 열기 에 등록하니,
더블클릭으로 gvim-vfs 로 가고 그 스크립트가 sftp 주소 형식을 고쳐서 gvim 에 보내어 잘 열렸었습니다.

지금은 다른프로그램으로 열기에 등록하고, 라디오버튼이 활성화 되어 있어도 더블클릭에는 걸리지 않는군요.

얼마전까지만 해도 파일형식이 어쩌고 하는 오류메세지만 나왔었는데 (gvim 메세지가 아니고 노틸러스 메세지) 좀 발전되긴 했군요.

노틸러스에서 참조하는 mime 정보를 수정해야 하는건지...
한다면 어느 파일인거죠?

우연히 생성된 이런 못된 파일들은 어떻게 되죠??

cat temp.txt
MP3 is 어쩌구 저쩌구

파일 헤더만 읽으면 mp3로, 확장자로만 읽으면 txt로
인식이 될 텐데..

그리고 파일 헤더를 읽는 게 빠를까요?
아니면 파일 확장자만 처리하는 게 빠를까요?
이건 테스트할 필요도 없는 문제 아닌가요?

또 *.sh, *.a, *.o같은 파일들은 그럼 뭡니까??
이것들은 도스 이전에 나온 걸텐데요??
또 확장자에 따라 의존관계를 형성해서 처리하는 Make만 봐도
알 수 있습니다. 음 확장자가 꼭 DOS시대의 유물이라고는 생각할 수는 없겠죠.

전 확장자로 우선 내용을 판단하고 이걸로 적절하게
표시할 수 없을 경우 MIME Magic으로 처리하는
순서가 맞다고 봅니다.

파일의 종류를 나타내는 필드가 현재 리눅스가 현재의 파일 시스템에
추가되기 전까지는 말이죠.

Ogg Theora 동영상도, Ogg Vorbis 손실압축 음성도, Ogg FLAC 무손실압축 음성도 모두 .ogg 확장자를 가집니다. (Speex 음성도 .ogg 확장자를 붙일 수 있습니다.)

Xiph.org의 Monty님은 확장자에 의존하는 것을 안좋게(?) 보시는 듯 합니다.

먼저 헤더 부분을 읽어서 보여주는 건 이미 1994년(사실은 그 이전부터이곘지만, 제가 본 격적으로 OS/2 를 쓴 게 그때부터라서...)부터 OS/2 에서 쓰이던 방식입니다. 당시 386 컴퓨터에서도 충분히 잘 보여주던 걸 실제 적용이 힘들지는 않을 겁니다. 다만, 요새는 600 메가 이상의 동영상 파일이 많아지니깐 그게 좀 문제가 될 것 같군요.

그리고 그 별도 필드 역시 OS/2 에서 이미 구현되어 있는 방법입니다. (HPFS 의 확장속성이 바로 그 별도 필드입니다.) 이미 1980년대 후반에서 1990년대 초반에 쓰였던 방법입니다.(지금도 쓰입니다.) - 확장속성 자체는 HPFS 가 아닌 FAT16 에서도 쓰일 수 있습니다. 다만, 루트 디렉터리에 파일을 2 개 더 만들어서 거기에 저장을 합니다.

마지막에 말씀하신 건 거꾸로 확장자가 잘못 되어 있다면... 그것도 같은 경우가 발생할 수 있습니다.

OS/2 같은 경우 일반 대중에게 퍼지는 것이 실패했기 때문에 그 구조를 그대로 현재 스케일에 도입한다면 이런저런 문제가 생길 것 같네요. 당장 사람들이 쓰는 파일형식이 훨씬 다양해졌고 새로 나오는 프로그램들이 생성하고 다루는 파일형식 같은 경우...헤더 규격을 엄격하게 통일하지 않는 이상 남이 받아보았을때는 이걸 뭘로 처리해야하는지 알 수도 없어지지 않을까요?

확장속성의 경우에도 결국 저장해서 안보여주는 것 보다는 명시적으로 보여주는 것이 사용자가 고치고 정리하기도 쉬운 편이고...서로 다른 파일시스템에서 복사 등의 처리를 하려면 모든 파일의 헤더 규격이 통일되기 이전에는 역시 파일명과 함께 다루는 것이 가장 효율적인 것 같습니다. (확장자라는 것이 일종의 통일된 필드라고 할 수 있으니 사실 파일 시스템에 확장자를 대신할 별도 필드 추가는 불필요해 보이네요. 리스트업 때 필드에서 읽어와 파일이름 뒤에 붙이는거라면 무슨 차이가 있을까요..)

현재 스케일에 도입한다 해도 전혀 문제 될 것이 없습니다. MS 의 광고대로라면 NTFS 는 HPFS 의 특징을 그대로 물려 받고 있으니까요. (문제는 NT 커널에서 그걸 제대로 못 해주고 있다는 것이긴 하지만요. 물론, 광고 그대로 믿기는 좀 께름직 하긴 합니다.) 그리고 위에서 언급한대로 JFS 파일 시스템 같은 경우는 이미 저러한 특징을 그대로 쓸 수 있습니다. 조금만 더 조작하면 되는 거죠. JFS 파일 시스템은 AIX 등에서 사용해서 이미 안정성 등을 충분히 인정 받은 파일 시스템이지요. - 조금 다른 관점에서 본다면 HPFS 는 JFS 의 서브셋이라고 보시면 됩니다.

이미 하드웨어적으로는 또한 소프트웨어적으로도 충분히 헤더 내용을 보고 어떤 파일인지 체크해주는 것은 가능합니다. 다만 말 그대로 아직까지는 그 궁합의 문제(파일 갯수가 몇만개쯤 된다고 할 때.. 단순히 파일의 확장자만 보고 파악하는 것과 각 파일들의 헤더를 쭉 훑어 보는 것은 분명히 확장자만 보고 파악하는 것이 '효율성'이라는 관점에서는 아무래도 떨어질 수 밖엔 없지만, 그 반대로 만일 그 수만개쯤 되는 파일중에서 확장자는 mp3 이지만, 내용이 ogg 이거나, 확장자는 xls 파일이지만, 단순히 텍스트 파일일 경우... 이런 경우 더 확실히 잡아낼 수 있다는 점도 있습니다.) 그리고, 결국은 과연 사용자가 느낄 때 느리냐, 빠르냐의 문제가 될 겁니다. 하지만, 제 경험으로는 ... 하드웨어적으로는 이미 충분하다고 봅니다. 문제는 메모리와 사용자가 어떻게 느끼느냐 .. 하는 점이지요. 이건 개발자들이 열심히 삽질해야 할 문제겠죠.

사용자 관점에서는 파일시스템(정확히는 OS 겠죠.)에서 파일 종류를 파악해서 보여주는 것은 단순히 확장자만 보여주는 것과는 상당히 다릅니다. 말씀하신대로 어떤 데몬에서 분석해서 틀린 확장자를 가진 파일을 찾아서 원래의 확장자로 돌려준다면 꽤 쓸만한 거죠.

즉, 확장자가 jpg 이기 때문에 jpeg 파일이냐, - 확장자로 구분하는 방법.
jpeg 파일이기 때문에 확장자가 jpg 가 붙느냐 - 확장속성 같은 것을 이용하여 구분하는 방법.
이냐로 문제를 좁힐 수 있는 것이고, 저는 뒤쪽을 더 선호하는 합니다.

여태까지 이러한 방식으로 헀을 때 문제 생긴 적은 한번도 없었거든요. 단순히 확장자만 가지고 작업하거나 했을 땐 문제 생긴 적이 많았지만 말이죠.

확장자 필드가 아니라 .. 확장속성에 대한 얘기였습니다...

그런데 한편으로는 이런 상황도 일어나죠 가장 기본적인 파일 포맷인(?) TXT파일입니다.다른 파일 포맷은 이미지파일이나 그런것으로 변형된다 하더라도 같은 프로그램에서 연동이 가능하겠지요.JPG파일로 인식된 PNG파일이라 하더라도 궁극적으로 여는 프로그램은 이미지 뷰어입니다.물론 헤더 속성으로 인해 JPG냐 PNG냐 설명이 달리 표기 되겠지만요.
하지만 기본적인 TXT파일은 무한히 확장이 가능합니다.즉 기본적인 텍스트 형태냐 그리고 프로그램 소스냐 아니면 웹페이지 소스냐 그리고 프로그램 설정파일이냐 천차 만별이고 또한 열어야 하는 적당한 프로그램도 달라집니다.이경우에는 어쩔수 없이 확장자를 이용해야 하지 않을까 생각합니다.확장자가 없으면 사용자가 어디에 쓰이는 프로그램인지 설명이 없다면 사용이 불가능할수도 있으니까요
이런 형식에는 압축파일 zip도 포함하는 것입니다.대부분의 스킨파일은 zip로 압축됩니다.윈도우즈 왠만한 프로그램은 그냥 복사하는 것 아니라면 zip로 해서 확장자만 달리해서 사용하고 있습니다.또한 자바의 JAR그리고 파이어폭스 스킨,확장도 역시 이형식으로 압축이 됩니다.이경우에도 역시 헤더만으로는 불가능하죠.