윈 도 우 '긴 파일이름'을 지원하는 윈도우에서의 확장자의 의미, 폴더의 의미
2010.01.16 03:17
일단 저는 전문가가 아닌 평범한 Windows 유저입니다.
파일시스템의 구조에 대해 자세히 모르더라도
Windows를 사용하는데에 불편함이 없는 그저 평범한 사용자입니다.
하지만 긴파일 이름을 지원하는 윈도우에서의 확장자의 의미와 폴더의 의미를
제가 깨우친 방법을 통해 설명하고자 합니다.
전문가들께서 보신다면 전혀 전문성이 없는 내용일 수 있습니다.
기술자료 등에는 관심도 없을 뿐더러 읽어도 무슨 말인지 모를 것이기에
저만의 무식한 실험 방법을 통해 스스로 깨우친 내용이라는 점을 먼저 말씀드리고 싶습니다.
테스트환경은 윈도우7과 NTFS입니다.
다른 윈도우에서는 다른 결과가 있을 수 있다는 점 미리 말씀드립니다.
NTFS에 파일이름이 저장될 때
'하나의 문자'가 유니코드(2Byte 이상)으로 저장되는 점은 배제하고 설명하겠습니다.
이 글에서 제가 말하는 '파일명에서의 문자 하나'는, 1Byte라는 의미가 아닌
그저 실제로 사용자에게 보여지는 하나의 문자(여기서는 영문/숫자만 사용하겠습니다)라는 점을 미리 밝힙니다.
제가 설명하고자 하는 사항은 3가지입니다.
[1] NTFS 파일시스템에서 파일명과 확장자의 구조를 설명할 때, 과거의 8.3형식으로 설명하는 것의 부적절함.
[2] '긴 파일이름'을 지원하는 윈도우에서는 확장자를 구분짓는 .(dot)도 파일명의 일부분일 뿐이다.
[3] 폴더도 파일이다.
[1] 긴 파일이름을 지원하는 윈도우에서의 8.3 파일명 구조의 의미
전문가가 아니기때문에 전문적인 설명은 생략하겠습니다.
과거 도스시절의 8.3의 고정적인 (파일명.확장자) 구조에 대해서도
파일명의 .앞쪽은 최대 8자
확장자(.뒷쪽)는 최대 3자까지 사용가능했다는 점만 알 뿐이지
디스크에 내부적으로 어떻게 기록되는지, 어떻게 처리되는지에 대해서는 모릅니다.
긴 파일이름을 지원하는 윈도우에서 8.3 구조를 함께 지원하는 이유는
당시에 8.3 구조에 맞게 작성된(컴파일된) 프로그램이
디스크에서 긴파일 이름을 변형된 형태로라도(ex: PROGRA~1) 입출력을 할 수 있도록
하위 지원을하기 위함이지
그 이상의 의미는 없다고 생각합니다.
아래는 QAOS 홈페이지에 소개된
"NTFS: 8.3 형식의 파일명 생성 안하기" 라는 게시물입니다.
https://qaos.com/article.php?sid=203
위 게시물의 내용에 따르면
DOS프로그램(혹은 일부 16비트 프로그램)과의 하위호환을 위해
NTFS에서는 8.3형식의 파일명도 함께 저장합니다.
이 8.3 형식의 파일명은 커맨드라인에서 dir /x 를 통해 확인할 수 있습니다.
그런데, 윈도우의 레지스트리 값을 수정하면
파일을 저장할 때 8.3형식을 파일명을 함께 저장하지 않는다고 합니다.
위 링크의 그림을 보시면 8.3형식의 파일명을 생성하지 않게 변경한 이후에 생성되는 파일은
8.3형식의 파일명이 표시되지 않음 dir/x를 통해 확인할 수 있습니다.
이런 파일의 경우
8.3 형식을 사용하는 구형 프로그램에서는 해당 파일 입출력이 불가능할 뿐
그 외의 NTFS 파일시스템의 작동에는 아무런 영향을 미치지 않습니다.
즉, 다시 말하면
NTFS를 얘기할 때 8.3 구조는 그저 하위호환을 위한 요소일 뿐이지
NTFS의 파일명.확장자 구조를 8.3의 Fixed한 구조에 맞추어 설명할 필요가 없다는 것입니다.
[2] 긴 파일 이름을 지원하는 윈도우에서의 유동적인 파일.확장자 구조
- 확장자를 구분짓는 .(dot)도 파일명의 일부분일 뿐이다.
(비단 NTFS뿐만 아니라 확장FAT16, FAT32의 경우에도 256자 긴파일 이름을 지원합니다.)
(다만, 동일 폴더내의 최대파일수 제한, 단일파일의 최대 크기, 파티션이나 볼륨의 최대 크기 등등에는 차이가 있을 수 있겠지만,
제가 전문가가 아니라서 자세한 것은 모르므로
여기서는 그러한 설명은 하지 않고, 단순히 파일명에 대해서만 실험을 통해 설명하겠습니다.)
일단 혼돈을 막기 위해 이 설명에서 사용하는 용어를 먼저 정리하겠습니다.
예를들어
windowsforum.txt 라는 파일에서
windowsforum 부분은 파일명앞쪽, txt는 확장자라고 부르겠습니다.
windowsforum.txt 를 통틀어 파일명으로 부르겠습니다.
전문가가 아니라서 정확한 용어를 모르기 때문에
파일명의 .(dot) 앞부분을 파일명앞쪽이라고 부르는 것을 양해해주시기 바랍니다.
과거의 8.3 구조에서는
파일명앞쪽은 최대 8바이트
확장자는 최대 3바이트까지가 가능했습니다. 즉 파일명이 .(dot)를 중심으로 8.3의 고정적인 구조였습니다.
그러나 긴 파일이름을 지원하는 윈도우에서의 파일명은 .(dot) 앞뒤로 고정적인 구조가 아닙니다.
기술자료를 인용하지 않겠습니다. 저는 기술자료를 봐도 이해도 못할 뿐더러 어디서 구해야 하는지도 모릅니다.
다만, Windows의 커맨드프롬프트에서의 실험을 통해서 이를 설명하겠습니다.
저의 실험 방법은 매우 무식하지만, 일관적입니다. 그를 통해 저 나름대로의 결론을 낼 것입니다.
그 결론이 기술자료의 내용과는 맞지 않을 수 있습니다만
저의 주장을 뒷받침하는 데에는 크게 무리가 없을 것이라 생각합니다.
긴 파일 이름의 최대 글자수
위에서 Z드라이브는 NTFS로 포맷된 드라이브입니다.
위에서의 파일은 확장자가 없는 순수한 '파일명앞쪽'으로만 구성된 파일입니다.
보시는 바와 같이 실제로 생성할 수 있는 파일명의 최대길이는 255자입니다.
이번에는 확장자를 1글자 넣어서 파일을 만들어 보겠습니다.
보시는 바와 같이 전체 파일명의 최대 길이는
확장자가 없는 위의 파일과 동일하게 255자입니다.
확장자가 10자인 파일도 한번 만들어보겠습니다.
위의 두 경우와 별반 다르지 않습니다.
그럼 .(dot)이 여러개 있는 파일을 한번 만들어볼까요?
.(dot)이 5개
확장자가 3자인 파일을 만들어보겠습니다.
어떻습니까?
위의 경우들과 전혀 다르지 않습니다.
여기서 2가지 결론을 얻을 수 있습니다.
(1) NTFS에서는 파일명앞쪽과 확장자의 길이가 최대길이 범위내에서 유동적일 수 있다.
(비단 NTFS 뿐만아니라, 긴파일 이름을 지원하는 윈도우에서 사용하는 확장FAT16, FAT32도 마찬가지입니다.)
(다만 제가 확장FAT16, FAT32까지 정확히 실험해보지 않았기때문에, 실험 결과는 NTFS로만 한정짓겠습니다)
=> 즉 과거의 Fixed한 8.3구조에 대입해서 설명을 할 필요가 없습니다.
(2) .(dot)도 그저 파일명의 일부이다.
=> 위의 그림들에서 보시는바와 같이 .(dot)도 NTFS의 파일명에서는 그저 한 문자의 공간 차지하는 문자일 뿐
파일시스템에 파일명앞쪽.확장자를 따로 분리해서 저장하기위해 사용되는 것이 아니라는 것을 알 수 있습니다.
그저 오늘날의 Windows에서는
파일명의 맨마지막 .(dot) 뒤의 부분을 기존의 확장자라는 개념으로 사용할 뿐입니다.
[3] 폴더도 파일이다.
전문가가 아니기때문에
폴더(디렉토리)가 파일시스템에 기록될 때
어떻게 기록되는지에대해서는 관심이 없습니다.
다만 위와 마찬가지 방법을 통해
폴더도 파일의 일종으로 취급된다는 것을 설명하겠습니다.
위에서 그림으로 설명한 바와 같이
실제로 '유효한' 파일명의 최대 길이는 255자 입니다.
그렇다면 폴더는 어떨까요?
폴더도 파일의 일종이라면
폴더 + 파일의 길이도 최대 255자일 것입니다.
그래서 실험해봤습니다.
루트에서 폴더 생성시
폴더명은 특이하게도 244자 까지만 생성이 가능합니다.
이것의 이유는 저도 잘 모르겠습니다만 계속 진행해보겠습니다.
244자인 폴더내에서 추가로 1자 폴더를 만드는 데에는 실패했습니다. (폴더명 길이 244자의 제한)
그러나 최대로 생성 가능한 파일의 길이는 11자입니다.
244+11 = 255
역시나 255라는 값이 나왔습니다.
이는 파일명의 최대 길이인 255와 동일한 값입니다.
그러면 243자인 폴더를 만들어서 같은 방법으로 실험해보겠습니다.
243자 폴더 내에서 1자 폴더를 만드는대에는 실패했습니다.
분명 루트에서 폴더를 만들때에는 최대 폴더명의 길이가 244자였는데 243+1=244임에도 불구하고 생성에 실패했습니다.
(이 이유는 잠시 후에 밝혀지며, 폴더도 파일이라는 것을 설명하는데에 결정적으로 작용합니다.)
243자 폴더내에서 최대로 생성할 수 있는 파일명의 길이는 12자로
243 + 12 = 역시 255가 됩니다.
242자의 폴더내에서 또 실험해보겠습니다. (이 부분이 매우 중요한 의미를 가집니다.)
아까전에 확인했듯이 루트에서 생성가능한 폴더명의 최대길이는 244자였지만
243자 폴더내에서 1자 폴더를 생성할 때에는 실패했습니다.
그러나, 242자 폴더내에서 1자 폴더를 생성하는데에 성공했습니다. 그 이유는 무엇일까요?
바로 아래의 이유입니다.
폴더를 구분하는 문자인 \(역슬래시) 때문이었습니다.
즉,
\(역슬래시) 문자도 역시 파일명의 일부입니다.
이 상태에서 파일을 또 생성해보겠습니다.
여기서 중요한 사실을 알 수 있습니다.
위에서 파일명과 확장자를 언급하면서
최대로 '유효한' 파일명의 길이는 255자인 것을 확인할 수 있었는데
폴더명+파일명에서도 마찬가지 결과가 나왔습니다.
폴더명+파일명의 최대길이가 255자가 나왔는데 이는
폴더를 구분하는 \(역슬래시) 문자도 파일명의 일부로 사용이 되어야 설명이 가능합니다.
즉, 폴더도 파일로 취급한다는 뜻입니다.
폴더라는 것을 나타내기 위해 파일명에 \(역슬래시)라는 문자가 들어가는 것입니다.
실제로 파일시스템에 폴더가 저장이 될 때에는 \(역슬래시)가 아닌 다른 문자가 사용될 수도 있겠지만
확실한 것은, '특정한 하나의 문자'로 폴더임을 나타낼 것이라는 것을 추측해볼 수 있습니다.
(자세한 파일시스템 구조는 모르므로 이 부분에 대한 자세한 설명은 생략하겠습니다)
조금 더 복잡하게 하위폴더를 만들어보겠습니다.
이제는 모든 것이 설명이 됩니다.
(다만 한가지,
왜 일반파일이 아닌 폴더명으로만으로 만들 경우에는 244자가 한계인가는 이 테스트방법으로는 설명할 수 없습니다.
이런 것은 기술자료등에서 찾아봐야 하겠지만 중요한 내용은 아닌 것 같습니다.)
위의 실험을 통해
폴더는 윈도우상에서 \(역슬래시)라는 문자로 구분이 되며
이 \(역슬래시)도 파일명(전체경로명)의 일부분이라는 점이라는 것이 설명됩니다.
그러므로 폴더도 파일의 한 부분이라는 설명이 가능해집니다. 게다가 바로 위 그림에서는
확장자를 구분지을때 사용하는 .(dot)도 그저 파일명의 일부분이라는 점까지 설명하고 있습니다.
(12345.abcde = 평범한 11글자의 파일명)
그러므로
위의 많은 그림들을 통해 설명된 것 처럼
(파일의 최대길이)나
(경로를 나타내는 폴더 + 실제파일이름)의 '유효한' 최대길이가 모두 255자인 점을 통해
이 둘간의 구분이 모호해짐을 알 수 있습니다.
즉 폴더도 파일로 취급할 수 있다는 것입니다.
그래서 윈도우에서는 파일명의 최대길이라는 용어 대신에
"최대 경로 길이"라는 용어를 사용하나봅니다. (그저 제가 얻은 결론일 뿐입니다.)
그런데 이쯤되면
NTFS에서의 최대경로길이는 256자라고 알려져있는데 (역시 기술자료는 생략합니다. 전문가가 아니라서 관심 없습니다.)
왜 위의 결과에서는 255자가 나왔을까 궁금해집니다.
그 이유는 위의 마지막 그림으로 설명하겠습니다.
위의 마지막 그림에서 생성한 파일명 abcdefghijklm 파일은
"경로명 + 파일명"의 전체경로를 가진 파일입니다. 즉 경로를 나타내는 \를 사용해서 표현하면 다음과 같이 표현될 것입니다.
1234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890\12345.abcde\hsk\winfo\abcdefghijklm
와 같은 전체경로를 가지게 됩니다.
위의 글자수를 세어보시면 알겠지만 정확히 256자입니다.
위의 그림들에서는 제가 \?를 생략하고 설명했기 때문에 255자로 보인 것이지
실제 파일 전체경로명에는 \?가 있다는 점을 생각한다면 256자인 것입니다.
이는 루트폴더에 있는 파일을 설명할때에도 가능합니다.
루트폴더에 windowsforum.txt 라는 파일이 있다면
이 파일의 전체경로는 \?windowsforum.txt 로 간주될 것입니다.
즉 파일시스템에 저장될 때에는
\ (루트) => OS에서는 폴더로 취급
Downloads\ => OS에서는 폴더로 취급
Program Files\ => OS에서는 폴더로 취급
....
Program Files\Internet Explorer\ => OS에서는 폴더로 취급
Program Files\Internet Explorer\iexplore.exe
....
Windows\ => OS에서는 폴더로 취급
Windows\ntoskrnl.exe
Windows\System32\ => OS에서는 폴더로 취급
....
\boot.ini
\ntldr
\windowsforum.txt
....
이와 같은 개념으로 저장된다고 말할 수 있습니다.
이 설명이 맞다면
폴더라는 개념은 결국
파일명 뒤에 \ 라는 문자가 붙은 파일이라고 생각할 수 있습니다.
즉
Downloads 라는 폴더가 있다면
Downloads\ 라는 파일로 생각해도 된다는 듯입니다.
물론 루트 폴더는
\ 라는 파일로 생각해도 되겠지요....
즉 아무리 복잡하게 서브폴더안에 서브폴더가 존재하더라도
결국 파일이름(경로명)에 \가 여러개 있는 파일로 취급되면 그만이라는 뜻이기도 합니다.
실제의 파일시스템에 기록될때에는 \가 아닌 다른 문자(토큰)로 기록되어 폴더임을 나타낼 수도 있겠지만
결국에는 OS에서 파일명을 읽어서 표시할 때
폴더를 나타내는 토큰이 있으면 해당 토큰마다 끊어서
폴더처럼 표시만 해주면 그만이라는 것입니다. \ 토큰이 여러개 있을 경우
여러개의 하위폴더로 취급되게 표시하고, 그에 맞게 처리만 해주면 그만일 것입니다.
파일을 이동하는 작업 역시 이로 설명이 가능합니다.
(볼륨, 파티션에 관한 자세한 설명은 생략합니다. 제가 자세한 것은 모릅니다)
같은 볼륨에서 파일을 다른 폴더로 이동하는 작업은 결국에는
내부적으로는 '경로명 이름 바꾸기 작업'이 될 것입니다.
Downloads 폴더에 nero_setup.exe 라는 파일이 있다고 한다면
이 파일의 전체 경로는
Downloads\nero_setup.exe 가 될 것입니다.
만약 이를 Files\라는 폴더로 옮기는 작업을 한다면 그저
전체경로명에서 폴더를 나타내는 부분만 이름을 바꾸어주면 될 것입니다.
Files\nero_setup.exe 이렇게 말이죠...
만약 여기서 Files\ 폴더 내에서 Install_Original\ 이라는 새폴더를 만든다면
내부적으로는 Files\Install_Original\ 이라는 파일을 만들면 그것이 새로운 폴더가 되는 것입니다.
Files\nero_setup.exe 파일을 Files\Install_Original\ 폴더에 이동하고 싶다면 역시
파일 이름(경로명)만
Files\Install_Original\nero_setup.exe 로 바꾸면 되겠지요....
결국 파일시스템이라는 것은
이러한 작업을 함에 있어서
효율적으로 그리고 안정적으로 저장장치에 저장하기 위한 자료구조일 뿐입니다.
적어도 제 생각에는 말입니다.
===========================================
글이 굉장히 길어졌습니다.
위의 실험을 통해 얻은 결론은 이렇습니다.
[1] 긴 파일 이름을 지원하는 윈도우에서 NTFS를 사용할 때, 과거 8.3의 Fixed한 파일.확장자 구조는 하위호환을 위한 것일 뿐,
그것으로 NTFS의 파일명 구조를 설명할 수 없다.
[2] 긴 파일 이름을 지원하는 윈도우에서는 확장자를 구분하는 .(dot)도 그저 파일명을 구성하는 '하나의 문자'일 뿐이다.
[3] 폴더를 구분하는 토큰인 \(역슬래쉬)도 결국 파일명(전체 경로명)의 일부이다. 그러므로 폴더도 파일이다.
제가 결론내지 못한 부분은 이것입니다.
\를 제외한 '유효한' 파일이름 길이는 최대 255자인데
왜 폴더로만 만들때에는 244자까지 밖에 만들지 못하는가 입니다.
실험을 통해 내린 제 결론에
잘못된 부분이 있거나, 보충해주실 부분이 있다면
기술자료나 또다른 실험을 통해 설명해주신다면
정말 많은 도움이 될 것 같습니다.
긴 글 읽어주셔서 대단히 감사합니다.
댓글 [7]
-
구경중 2010.01.16 06:58 -
하영 2010.01.16 07:00 성의있게 쓰긴 긴 글 잘읽었습니다.
말씀하신 대로
[긴 파일 이름을 지원하는 윈도우에서 NTFS를 사용할 때, 과거 8.3의 Fixed한 파일.확장자 구조는 하위호환을 위한 것일 뿐,
그것으로 NTFS의 파일명 구조를 설명할 수 없다.]
라고 저도 생각합니다.
저는 NTFS 파일 시스템의 구조에 대해서는 무지하기 때문에, NTFS 파일 시스템 상 실제 파일 이름은 긴 파일 이름이 되는지, 8.3 파일 이름이 되는, 둘다 아닌 새로운 개념의 임의의 문자가 되는지 모릅니다. (개인적으로는 임의의 문자가 될 것으로 생각하고 있습니다.)
그러나 제가 그것과 상관없이 확장자를 가질 수 있다고 말한 이유는 아래와 같습니다.
FAT 파일 시스템에 긴 이름이 index.html 인 파일이 있을 때 실제 파일 이름은 8.3 파일 이름인 index.htm이 되는데
그때 FAT 파일 시스템의 실제 확장자는 htm 이지만 (엄밀히따져 파일 이름이 아니고 단순히 주석에 불과한) 긴 파일이름에서 마지막 점 뒤에 있다는 이유로 html을 확장자라고 말 하듯이
같은 논리를 NTFS까지 적용 시켜보았을 때 NTFS에서의 실제 파일 이름이 설사 우리가 볼 수있는 긴 파일 이름 혹은 8.3 파일 이름이 아닌 NTFS만의 임의의 문자라고 해도 8.3 파일 이름 또한 반드시 가지게 되므로 NTFS에서 실제 파일 이름이 아닐 수 있는 8.3 파일 이름의 확장자 또한 확장자라고 말할 수 있게 되지 않느냐라는 생각을 해봅니다. 아시다시피 8.3 파일 이름에서는 점은 무조건 가질 수 없기 때문에 긴 파일 이름의 확장자의 3글자까지는 무조건 확장자가 되기 때문입니다.
저도 폴더가 파일인 것은 NTFS도 FAT와 마찬가지인 것 같습니다. 이게 파일이 아닐 경우에는 어떤 파일과 동일한 이름의 폴더를 만들 수 있어야하며(이 부분은 실제로는 동일한 문자를 배당 하는 것이 가능하지만 단순히 FAT와의 호환성을 위한 것일수도라고 단순히 생각할 수 있습니다만) 시간/날짜 정보의 기록/읽기와 NTFS에서 추가된 사용자 보안 소유자 개념까지 생각해보았을 때 각각의 폴더를 파일의 단위로 존재시킬 때의 효율성이 최고이기 때문이라고 생각합니다. 그런 것을 다 떠나 NTFS<=>FAT간의 파일 교환의 효율성을 생각했을 때도 NTFS에서의 폴더의 개념이 파일과 동등하지 않으면 안됩니다. 그렇지 않으면 OS차원에서 컨버팅 과정이 필요한데 MS가 이런 불필요한 헛수고를 할 이유가 없다고 생각합니다.
저 또한 왜 폴더의 이름의 최대 길이가 224자가 되는지는 생각해본 적도 없기 때문에 잘 모르겠습니다.
이 부분이 굉장히 궁금합니다.
NTFS구조에서는 긴 이름 파일에 역슬래시가 자동으로 들어가서 폴더를 의미하게 할 수는 있다고 생각하나, 8.3 파일 시스템에는 \가 들어갈 수 없기때문에 FAT 파일 시스템과의 호환성을 생각할 때 그렇게 보기에는 힘들지않는가라고 생각합니다.
FAT파일 시스템에서 파일과 디렉터리는 본질적으로 동등하게 표현하지만 어떠한 기술적인 이유로 폴더의 긴 이름을 224자까지밖에 표현할 수 없었기에 NTFS에서도 224자까지 가능하도록 설계했을 것으로 저 나름대로 추측해봅니다.
나이가 있는 시점에서 새로운 것에 대해서 파고들 열정이 사그라든지 오래라 사실 NTFS 파일 시스템에 대해서 공부할 의욕을 느끼지는 못합니다. 그러나 그 까닭을 알고 싶은 것은 예나 지금이나 마찬가지인 것 같습니다.
-
Boss 2010.01.16 13:11 1번 과 2번 은 지리할만치 다룬 내용 이므로 Pass 하구요 ^^
3번 폴더 도 파일이다.
이 부분 은 일견 이해가 되기도 하고 안되기도 하고 그러네요
단순화 시켜서(확대) "0과1의 조합 이므로 그러하다"
하신다면 저 역시 그리 생각 합니다. 어차피 파일 이름이나 폴더의 이름등으로 구분 짓는것 은
0과1 뿐인 기계어 를 우리눈에 보이도록 인터페이스 를
그리 할당하고 구분짓고 분류한 그 이상 도 이하도 아닐것 이기때문 입니다. 이는 확대한 개념 에서의 명제가 됩니다.
그러나 윈도우 안에서 (위 설명이나 이미지들 역시 NTFS이지만 프롬프트상이죠) 는 인터페이스 상
파일 과 폴더라는 각기 고유한 이름 을 가집니다.
먼저 하영님 의 이전 게시물 에서는
해당 파일 이 있어도 해당번지(경로 <폴더>)가 없으면 오류 가 난다 였지만
마찬가지로 해당 경로(폴더) 가 잇어도 해당하는 파일 이 없으면 마찬가지 로 오류 가 생기죠
더불어 두가지 조건 을 충족 시키더라도 해당경로 의 해당 파일 이 형식 이 다르다던가(이름으로서 의 확장자 가 아닌 포멧형식에 따른 확장자) 하면 역시 오류 가 발생 하죠
나아가서는 다 충족하더라도 해당 파일 의 데이터 가 필요한 파일 과 다르다면 (해당 파일 이 이미지 파일이고 같은 이미지인 파일 이더라도 데이터값과 다른 데이터의 이미지파일) 역시 오류 가 납니다.
윈도우 의 시스템폴더 안에는 로컬 호스트 정보 를 담고있는 확장자 없는 파일 이 있습니다.
이처럼 도스 시절엔 그 필요성 조차 인식되지 않던 파일들 도 있죠
이러한 파일 은 도스개념 에서의 구분 은 모호하기 이를데 없습니다.
도스의 파일관리측면에서 보자면 요 시스템 파일 이기는 하되
시스템장치 에 관계된 파일 이기도 하거니와
그러나 도스 시절엔 그 효용성 자체 가 언급되지 않았던 그런파일 이니까요
텍스트 기반 의 도스 를 탈피하여 세로운형식으로 이미 상당히 변화하여 발전해 왔고
이는 지금도 꾸분히 그러합니다.
제가쓰는 XP 저도 언제까지 이 운영체제 를 쓰게될진 모릅니다.
사실 이 운영체계 가 특별히 좋아서 쓰는것 이 아니니 자의적인 선택 은 아니겠죠
위에 하영님 께서 말씀 하신것 처럼 과거와 같은 흥미롭고 알고싶고 하나라도 배워야겠다 하는
의욕? 열정? 그런것 이 사그라든면 없지는 않을겁니다.
허나 저 역시도 알고싶기는 마찬가지 입니다.
그 내가 알고싶어하는 이유 가 나보다 더 안다는 사람들 에 의해
조금 더 아는 사람들 때문에 그들로부터 "바보취급"당하는것 이 싫어서가 아닌
저 스스로 알고싶기 때문 이었으면 합니다.
하영 님 처럼 저 역시도 사람 이라서
감정의 영향 을 많이 받습니다.
그런점에서 지난밤 다소 무레하게 행동한점 다소 기분 상할수도 있었을 단어로 자극한점
이 자리를 빌어 죄송하다고 전하고 싶습니다.
글쎄요 표현력 이라거나 이해의 폭 때문 이라고 저 스스로 정당화 하여 표현 합니다만
나름 의 과정이나 흐름에대한 그림 은 제 머릿속에서 그려지지만
저의 생각하는바 를 명확히 표현하지 못하여 그 생각 을 보여드리지 못함 때문에
말하자면 같은것 을 말 하더라도
한쪽 은 들으려 하지않고 또다른 한쪽은 듣는이의 눈높이를 몰라 서로 동문서답 하고
그로인헤 생기는 오해 정도 라 말 하고 싶습니다.
꼭 필요하다면 어떻게든 알려하지 않을까 합니다.
당사자 가 아니라면 그 사람이 하고자하는 말 의 진위 를 모르는게 당연하다 생각 합니다.
그렇기에 쉽사리 내 생각안에서 이렇다 저렇다 미리 단정지어 버리는것 이
그 오해 를 키우지않나 생각 도 해 봅니다.
워낙 윈포 가 연령대 가 높아서...조금 이라도 어린제가 버릇없이군점 이 있다면 다시한번 사과드립니다.
이 나이타령 이 또 하영 님 의 심기 를 건드리진 않을지...
-
hsk 2010.01.16 14:24
모든 분들의 의견을 존중합니다.
용어를 설명할 때 서로 조금씩 다른 방법으로 설명하기에
이러저러한 오해가 생기는 것 같습니다.
다만
'확장자'라는 용어가 과거 도스시절과 비교했을 때 현재 윈도우를 사용함에 있어서는
과거의 개념을 포함하면서도 조금 더 확대된 개념으로 받아들이면 될 것 같습니다.
폴더의 경우도 이와 비슷하게 받아들여야 할 것 같습니다.
과거의 디렉토리개념을 포함해서 더 확대된 개념 쯤으로 말입니다.
'윈도우에서 말하는'
확장자의 정의, 폴더의 정의를 정확히 기술한 문서가 있다면 그것대로 받아들이면 되겠지만
그러한 정확한 자료를 제시하지 않고, 서로 자신의 방법으로 설명을 하다보니
동의하지 못하는 부분이 생기고, 그로인해 의견충돌이 발생한 것이라 생각됩니다.
저또한 저의 방법으로 확장자와 폴더의 개념을 설명한 것 이라서
하영님과 Boss님, 유기농초코님, 그리고 다른분들이 동의하지 못하는 부분이 있으니 말입니다.
(그래서 위에서의 제 실험을 '증명'이라고 하지않고 '설명'이라고만 말했던 것입니다)
'파일' 이라는 용어를
일반파일, 폴더, 등등등... 의 여러종류의 파일의 '대분류'를 의미하는 이름으로 볼 것인가
파일이라는 용어를 우리가 흔히 생각하는 '일반파일'로만 정의할 것인가에 따라서도
서로 의견이 발생할 수 있으니 말이죠...
가장 중요한 것은'용어의 정확한 정의'를 먼저 내린 후 그에 맞게 서로의 의견을 나누는 것이라 생각합니다.
사실판단을 하면 되는 성격의 문제를
서로의 가치판단 문제로 생각하고 논쟁을 했기 때문에
불필요한 논쟁이 생긴 것입니다.
용어의 정확한 정의가 기술문서등에 정의되어있다면서로 가치판단을 할 필요가 없이
사실판단만 하면 되는 부분이지만
그러한 기술문서없이 용어도 정의도 모호한 상태에서 서로의 주장을 가치판단하기 때문에
논쟁이 생겼던 것 같습니다.
(윈도우에서) 확장자가 무엇인가?
(윈도우에서) 폴더는 무엇인가?
폴더도 파일인가?
파일시스템의 구조는 어떻게 되는가? 하는 문제가 과연
가치판단을 할 문제일까요?
적어도 컴퓨터의 입장에서는 그렇지 않습니다.
그저 정의된대로만 작동할 뿐이기 때문이지요......
그 정의와 용어가 정확하게 제시되지 않은 상태에서 사람들이 서로 의견을 나누다보니
사실판단의 문제를 가치판단의 문제로 잘못 생각하는 것입니다.
윈도우에서의 확장자, 폴더, 파일... 등의 개념이 정확히 정의되어있는
공식적인 기술문서만 제시된다면
서로 그 사실을 사실로써 받아들이기만 하면 될 뿐인 것입니다.
저도 모르는 점을 많이 배웠습니다.
지식이라는 것이 꼭 문서를 통해서만 배울 수 있는 것이 아니라는 점도 말입니다.
무식한 저의 실험방법도 결국 Trial & Error Method 인데,
그 결과가 비록 틀리다고해도, 다른 분들께서 인정하지 않는 부분이 있다고 해도
'저에게 있어서'는 그 결과는 확고한 결과일 것입니다.
다른 분들도 마찬가지겠지요...자신의 Method로 자신의 의견을 뒷받침 하는 것이
다른 사람에게는 틀리게 보일 수 있지만, 자신에게는 확고한 결론인 것입니다.
(용어와 개념이 확실하게 정의되고 설명된 공식적인 문서가 제시되어서, 사실판단만 하면 되는 상황이 오기 전까지는 말이죠)
즉, 가치판단을 하는 문제에 대해서는 서로서로를 인정해야 하는 부분이 있는 것 같습니다.쓸데없이 말이 길어졌네요 ^^ 죄송합니다.
서로가 자신의 의견만으로 말하지 않고 다른 사람 의견에서 공감가는 부분을 모을 수 있다면
좋은 결과가 나올 수 있을 것이라 생각합니다.
더 이상의 소모적인 가치판단 논쟁은 서로 삼갔으면 좋겠습니다
위의 문제들은 사실판단만 하면 되는 문제입니다.
감사합니다.
-
흥인지문 2010.01.16 15:22 제가 쉽게 이해한 것은 이것인데요,
모든것들이 파일로인식합니다.
단, 여기서 또 구분되어야 할 것은 파일, 즉 최종적으로 사용될 수 있는 데이터의 집합체를 최종적인 파일로 보고있고요, 그런 파일집단의 주소(링크)를 모아 놓은 파일을 폴더(디렉토리)라고 이해하면 쉽습니다.
자료구조 약간 배웠기 때문에 제나름데로 이해한건데요.
확장자있느냐 없냐는 무의미한 것 같습니다.
우리가 편하게하려고 뒤에 확장자를 두어 파일이 실행될때 어떤 응요프로그램을 실행시킬건지를 판단하기 위해 확장자라는게 생겼다라고 이해하시면 될듯합니다.
-
Boss 2010.01.16 18:47 예 각자 자신이 이해하기 쉬운 방식 이 있을겁니다.
중요한것 은 윈도우 는 특별히 어려운 도스 나 프로그레밍 언어 를 배우지 않은 사람도 쉽게 사용하도록 만들어진
도스에서부터 더더욱 쉬운 사용을 위해 다듬어진 그런 운영체계 라는것 일겁니다.
물론 어렵고 복잡한 도스 나 프로그레밍 언어등 을 안다면 더 여러가지 기능 을 원활히 이용할 수 있겠죠
그것 은 당연한것 입니다.
전자제품 하나 를 보더라도 갈수록 사용하기 편하고 쉽게 만들지 더 어렵고 까다롭게 만들지는 않으니까요
따라서 윈도우 는 어려웃것 자체 를 더 쉽게쓰기위해 발전시킨형태 로 인식하는것 이 될것 같습니다.
위에서 본문을 쓰신분 께서고 언급 하셨다시피 딱히 무어라 단정지어 규정 할만한것 없이
제각각의 방식으로 나름 의 지혜 를 터득한것 이 여러 오해 의 이유 가 되지않나 싶어요
그도 그럴것이 각각의 명칭에 대해 정의하는바 가 국어사전,컴퓨터용어사전,운영체계별 문서(각각 이 차이가 있습니다)등
제각각 입니다. 이또한 발행시기에 따라 또 달라집니다.
물론 이는 싯점에 따라 추가되고 보완되고 제정립되고 등의 이유 가 아닐까 싶구요
예로 제가배운 시대 의 국어 맞춤법 과 현제 의 그것 이 다른것 처럼 요
어느하나 틀리다고 단정 할 수 도 맞다고만 단정 하기도 애매한것 입니다.
말하자면 이해 를 한것이냐 암기 를 한것이냐 의 차이 랄까요?
그다지 아는것 이 별로없는 제 입장에서 보자면 고급지식 을 습득하신분 은 자신의 눈높이에서 말씀 을 하십니다.
허나 아는것 이 없는 저같은 사람 은 단순히 비슷하게 줄세우고 부분부분 만 짜 맞추는식 이거든요
개념 은 대~충 파악하되 설명을 하려면 (특정 지칭 이나 표현식)에서 쓸데없는 마찰 이 생깁니다.
전문지식 이 있는분들 끼리 는 그들 나름의 대화 가 가능 합니다.
또 별스럽지만 별로 아는것 없는 사람끼리 도 대화 가 가능 합니다.
이유 는 아는사람 은 아는범위의 대화이기에 대화 가 되고
모르는 사람 은 모르는 사람 특유 의 넓은 의미 를 개념처럼 이해 를 하기에
융통성 이 더 많다고 할까요? 전문인 끼리 는 콕 찝어서 하는 대화 가 되는것 이고
비전문인 은 그 나름 의 포괄적인 이해차원 의 대화 가 되는것 이죠
결국 말하는 그 본질 은 같을 지라도 표현하는 방식에서 차이 가 있고 그것이 오해 를 만든다는것 입니다.
사과 를 파일이라 하고 그것을 담은박스 를 폴더라 이해 를 하는것 처럼 말이죠
사과 는 그 과일 의 특성 이며 그것 이 이름이자 확장자 인것 처럼 요
그 박스 를 모으면 한차 가 되고 이것 이 좀 더 큰 범위 의 디렉토리 입니다.
이들이 모인 단위 를 컨테이너 ( 파티션) 의 개념으로 본다는것 처럼 요
요소 의 차이 는 있을지라도 전체적인 관점에서 크게 어긋나지는 않습니다.
물론 비전문가 의 입장에서 요
아울러 각기 전문이신 분들 은 기왕 자신의 지식 을 나누고자함 이시라면
전문가적 시각에서 가르치려 하기보단 이해 못하는 부분 을 이해할 수 있도록 어드바이스 정도로 해주시면 좋을거 같습니다.
대부분 은 사용이 목적인 사람일뿐 전문적으로 프로그레밍 을 한다거나 컴퓨터 자체 를 업으로 삼는 그런것 은 아니거든요
커뮤니티 란 의 우스게 같은 그런 황당한 질문을 하지 않으리란 보장 이 없는 그런 초보자들 이 많다는것 을 염두하셔서
좀 더 넓은 아량 과 나누다 하는 배려의 입장에서 지식을 나누심 이
그 알려주신다 는 취지 에 더 이상적일것이라 생각 합니다.
-
하영 2010.01.17 01:54 마지막으로 감히 무례한 말씀 올리겠습니다.
저라는 개인이 타인에게 어떠한 부정적인 감정은 추호도 없음을 미리 말씀드리겠습니다.
감히 말씀드리는 것이지만 보스 님은 현재 이 부분에 대해서 현재 완전히 잘못된 개념을 가지고 계십니다.
이 글에 달린 2개의 댓글에 서술된 내용, 어제 토론에서 발언하신 내용의 거의 대부분이 틀린 내용들입니다.
저의 글은 왈가불가할 여지가 못되는 '이미 정해져 있는 규칙'을
지식이 없는 분들이 적어도 감 정도는 잡을 수 있게 혹은 경험적인 것을 개념적인 정답으로 이끌어 주려는 목적을 가지고
지식적인 측면이 아닌 우리 눈에 보이거나 실제로 쉽게 접할 수 있는 예로서 설명하고 싶었습니다.
따라서 이것을 받아 들이자는 시선에서 보지 않는다면 저 개인의 정당화하기 위한 목적으로 느끼실 수도 있다고 생각합니다.
만약 이 분야의 전문인으로서 사회에 활약하시거나 활약하실 분이시라면
부디 이 부분에 대해 꼼꼼히 살펴 보시어 사회의 주역이 되시기를 감히 부탁드리겠습니다.
서로 본의아니게 얼굴을 붉히게 되어 죄송스럽습니다.
번호 | 제목 | 글쓴이 | 조회 | 등록일 |
---|---|---|---|---|
[공지] | 질문과 답변 게시판 이용간 유의사항 | gooddew | - | - |
11718 | 하드웨어| FLASH 프로그램 [1] | 민초의삶 | 2516 | 01-16 |
11717 | 윈 도 우| 제질문만 답이 없어서 같은 질문다시올립니다. [15] | 강가딘 | 4134 | 01-16 |
11716 | 윈 도 우| 64bit xp language_pack 올려주세요 | kk789 | 3318 | 01-16 |
11715 | 윈 도 우| 블랙 스크린 뜰 때... [3] | 파닥파닥 | 9064 | 01-16 |
11714 | 윈 도 우| DLL 자동설치팩 만들기 비법 공개 [3] | 진모씨 | 8134 | 01-16 |
11713 | 윈 도 우| IEToy 2.0 스마트로그인이 이상하네요;; [5] | 코디알 | 4578 | 01-16 |
11712 | 윈 도 우| 멀티부팅 선택메뉴 나타나게 하려면.... [2] | 떠오름 | 2638 | 01-16 |
11711 | 윈 도 우| ATI 카드 쓰시는 분들 CCC 9.10 한글 버전 좀 찾아주세요~ [3] | 코디알 | 3037 | 01-16 |
11710 | 윈 도 우| 윈7에서 폰트 변경 방법을 알고 싶습니다.(레지 수정으로) [1] | 과거지사 | 4409 | 01-16 |
11709 | 하드웨어| 윈도우 포럼이 RSS를 지원하나요? | 후레이 | 2355 | 01-16 |
11708 | 윈 도 우| 2008 R2 사용중인데요 테마관련 질문입니다. | wooolk | 2628 | 01-16 |
11707 | 윈 도 우| InfraRecoder 리뷰 및 강좌 [9] | 진모씨 | 6960 | 01-16 |
11706 | 하드웨어| MS 시큐리티에센셜 한글판은 언제 나올까요? | 피에스피 | 2989 | 01-16 |
11705 | 윈 도 우| (긴급 help) Missing Operating System 에러로 부팅이 안됩... [2] | nkino | 5982 | 01-16 |
11704 | 서버 / IT| 서버 2008 R2 설치후에도 DVD가 꼭 들어있어야 부팅이 되네... [3] | hoony | 3647 | 01-16 |
11703 | 하드웨어| 64비트 익스플로어 플레쉬 문제.. [4] | 박종환 | 3439 | 01-16 |
11702 | 윈 도 우| MS Office Beta2 14.0 4730 [1] | 산정 | 2829 | 01-16 |
11701 | 윈 도 우| 자동업데이트에서 IE7 보안업데이트(kb976325)가 반복 설치... | HaeAhnyo | 3931 | 01-16 |
» | 윈 도 우| '긴 파일이름'을 지원하는 윈도우에서의 확장자의 의미, 폴... [7] | hsk | 16031 | 01-16 |
11699 | 윈 도 우| 포멧 질문드려요 ㅠㅠ [2] | 너에게 닿기 | 3196 | 01-16 |
255자와 244 자의 차이는 아마도 내부적으로 일반파일과 디렉토리파일을 구분하기위해 11자를 이용하는게 아닐까하는..;;