봉래안녕Ȣ16;세요. 1060;,148; 큰 Ƽ17;금1613;1008; 아니고 그냥 오늘 겪1008; 1068; ǐ12;문에 올리lj16; 1656;문1077;니다.
기본1201;1004;론 ᅆ1;/196;명1060; 2601088;를 초과Ȣ16;lj16; ᅆ1;우 윈도우 탐색기/196;lj16; 편1665;1060;나 삭1228;가 불가능Ȣ16;고, 서드파티 프/196;그ǖ16;1012; 사용해야 Ȣ16;lj16;데,
1060;0120;들 아시,192;1648;만 윈도우 내에lj16; 1060;0120; /196;컬 그룹 1221;책1060;나 /112;1648;스트리 편1665;1012; 통해서 2601088; 1228;한1012; 해1228;Ȣ16;lj16; Ꮢ1;션1060; 1316;1116;합니다.
1060; Ꮢ1;션1012; 디폴트값1004;/196; 해도 .112; ,163; 같1008;데 그러1648; 않lj16; 1060;유가 ᕬ1;시 뭔가요? 파1068; 시스템상 뭔가 문1228;가 1080;lj16;,148;1648;..
Linux에서는 1024나 2048로 되어 있는 경우가 많습니다.
그런 시스템을 SAMBA나 NFS등을 사용해서 네트워크 드라이브로 사용하려문 문제가 발생하겠죠
좀더 고민해 보면, NTFS, FAT32는 대소문자를 가리지 않는데 Linux는 가리죠. 그런 Linux를 Network Drive로 연결하면 어떻게 될까를 생각해 보시면
뭔가를 default로 설정하는게 위험할 수 있다는걸 알수 있습니다
맥이랑 윈도 기본은 대소문자 미구분이지만, 커널 구조는 지원하게 되어있습니다 (실재로 마운트해보면 아무 문제 안 생김)
윈도 과거에는 POSIX 인증 받은적도 있다보니 이런것 다 되요
File System관련 POSIX 표준에는 대소문자 관련한 내용이 없습니다.
파일 시스템도 지원 잘 되고, 저장된 경로 접근해서 파일 각각 접근하는데도 아무 문제 없습니다 (커널도 정상 처리)
무한정 늘릴순 없고 유산을 그대로 따라온게 아닐까 합니다.
그리고 사람이 너무 길면 쓰기 힘들어서 적당히 쓰다 보니 8.3 규격으로만 해도 32 depth의 디렉토리 접근이 가능한 규격이니
의외로 유지될지도 모르겠습니다.
폴더 혼자 수십자는 잡아먹어버리는데도 경로 상한을 저러고 있으니 문제죠
260자 제한 없어진지 10년도 넘었습니다
근데 별도 전용 프로그램으로 포맷한 그 윈도우 자체 만들 수 있는 제한보다 큰 사이즈도 읽는데 문제가 없었죠
윈도우 홈버전 프로 버전에 따라 인식할 수 있는 램 사이즈가 다릅니다
마소는 참으로 이유가 궁금한 짓을 많이 합니다 ㅋ
당장 팟플레이어 같은 것만 해도 전체 경로가 길면 동영상 인식이 안 됩니다.
그냥 인식을 못하면 다행인데 이상한 오류로 데이터를 날려먹을 가능성도 있죠.
그런 프로그램들이 한 두 개가 아니니까 무시할 수도 없습니다.
어차피 정책 편집기로 수동ㅇ로 활성화하는거니 사용자가 자가 책임으로 하는 부분입니다
문젠 최저한도로 윈도 내장 탐색기등의 소프트는 저런 기능이 존재하는 이상 260자 제한에 안 걸려야 하는데, 안 된다는점이죠 (저럴바엔 왜 기능을 만든건지)
또한 새로 만들어지는 프로그램 역시 그런 과거의 제약을 무시하지 못하기 때문에 일부러 예전처럼 만들기도 합니다.
탐색기도 결국 그런 제약에 맞춰서 만들어가는거죠.
애플처럼 다 뒤집어 앞고 호환 안되면 새로 사라고 하면 되는게 아니니까요.
대다수를 위해서 과거의 호환성을 유지하는거니까
반대로 필요한 사람은 여타 유틸리티를 쓰면 되는 겁니다.
켠다음 데이터 손상등이 일어나도 결국은 사용자 책임입니다 (이로 인해 책임지는게 문제된다면 애초에 저런 옵션자체가 없어야 합니다)
딱히 탐색기등이 저런 제약에 안 메인다고 동영상 플레이어같은게 망가지거나 할일은 없습니다 (기컷해야 긴 경로의 파일 열떄 파일 없다고 뜨는정도겠죠)
애플처럼 하란건 아니지만, 최저한도로 옵션을 켜면 레지를 읽어서 내장엡도 거기 맞추어서 같이 사항이 변경되는식으로 만들었어야 한다는겁니다 (개발 부서가 따로 있는건 알겠지만, 하나의 상품의 기능이 완전히 따로 노는건 문제가 있다고 봅니다)
저 옵션이 추가된지가 언제인데 아직도 이런식인지 모르겠네요 (그리고 아무리 하위 호환성이 중요해도 9x시절에 나온 api를 아직도 호환시키기 위해 노력하는건 너무 과하다고 봅니다)
거기다 호환성 중시한다는 윈도의 Hi-DPI 호환성은 리눅스보다도 못한 꼴찌입니다 (심지어는 윈도 자체UI조차 비율 제대로 처리 못해서 레이아웃 깨지거나 합니다) (애초에 고 해상도 쓰는걸 시험하는지 설계하는지 궁금한게 4,5k 모니터 쓴다고 모니터 해상도에 맞는 해상도 이미지 파일에 우클릭해서 배경 그림 지정 시도하니 변환 실패하는지 검은 배경으로 바뀌어서 이미지 뷰어로 열어서 지정하니 정상적으로 될 정도입니다)