통신버필 2022-02

W95시절 레거시 호환문제로 알고있습니다.

epowergate 2022-02

260자 제한은 탐색기가 가지고 있는것이지 파일 시스템이 가지고 있는게 아니기 때문에 그렇습니다.
Linux에서는 1024나 2048로 되어 있는 경우가 많습니다.
그런 시스템을 SAMBA나 NFS등을 사용해서 네트워크 드라이브로 사용하려문 문제가 발생하겠죠

좀더 고민해 보면, NTFS, FAT32는 대소문자를 가리지 않는데 Linux는 가리죠.  그런 Linux를 Network Drive로 연결하면 어떻게 될까를 생각해 보시면
뭔가를 default로 설정하는게 위험할 수 있다는걸 알수 있습니다

dateno1 2022-02

아무 상관없습니다

맥이랑 윈도 기본은 대소문자 미구분이지만, 커널 구조는 지원하게 되어있습니다 (실재로 마운트해보면 아무 문제 안 생김)

윈도 과거에는 POSIX 인증 받은적도 있다보니 이런것 다 되요

epowergate 2022-02

Kernel과 대소문자는 아무런 관계가 없습니다.
File System관련 POSIX 표준에는 대소문자 관련한 내용이 없습니다.

dateno1 2022-02

ntfs case sensitive라고 검색해보세요

파일 시스템도 지원 잘 되고, 저장된 경로 접근해서 파일 각각 접근하는데도 아무 문제 없습니다 (커널도 정상 처리)

epowergate 2022-02

posix하고 상관없고, 표준하고 상관없고, kernel하고도 상관 없는겁니다

dateno1 2022-02

파일 이름을 제대로 저장할려면 파일 시스템이 지원해야 하고, 소프트가 접근하는걸 제대로 처리해줄려면 커널도 지원해야 합니다

구차니 2022-02

MS적으로 표현하자면.. 정책입니다. 로 요약할 수 있을 것 같습니다.

봉래 2022-02

맞는 말씀입니다. MS의 정책같은데.. 굳이 저런 정책을 만든 이유가 뭔지 궁금하네요.

구차니 2022-02

개인적인 추측으로는 ms dos 시절부터 path string의 length를 256으로 해왔었으니
무한정 늘릴순 없고 유산을 그대로 따라온게 아닐까 합니다.
그리고 사람이 너무 길면 쓰기 힘들어서 적당히 쓰다 보니 8.3 규격으로만 해도 32 depth의 디렉토리 접근이 가능한 규격이니
의외로 유지될지도 모르겠습니다.

dateno1 2022-02

문젠 스토어 엡등의 폴더명이 더럽게 길어요

폴더 혼자 수십자는 잡아먹어버리는데도 경로 상한을 저러고 있으니 문제죠

dateno1 2022-02

아무 문제 없는데 호환성을 핑계로 순정 엡은 언제까지고 그걸 고집하는것뿐입니다

260자 제한 없어진지 10년도 넘었습니다

코인시덴샤… 2022-02

FAT32 도 윈도우에서는 포맷 할수 있는 사이즈가 본래 FAT32 규격의 최대 사이즈보다 작았죠
근데 별도 전용 프로그램으로 포맷한 그 윈도우 자체 만들 수 있는 제한보다 큰 사이즈도 읽는데 문제가 없었죠
윈도우 홈버전 프로 버전에 따라 인식할 수 있는 램 사이즈가 다릅니다
마소는 참으로 이유가 궁금한 짓을 많이 합니다  ㅋ

dateno1 2022-02

그건 NTFS를 강요하기 위해 고의로 그런것같아요

drachen 2022-02

하위 호환 때문이죠.
당장 팟플레이어 같은 것만 해도 전체 경로가 길면 동영상 인식이 안 됩니다.

그냥 인식을 못하면 다행인데 이상한 오류로 데이터를 날려먹을 가능성도 있죠.
그런 프로그램들이 한 두 개가 아니니까 무시할 수도 없습니다.

dateno1 2022-02

케케묵은 API를 쓰니 그런겁니다 (현제 그런걸로 문제되는 소프트는 소수입니다)

어차피 정책 편집기로 수동ㅇ로 활성화하는거니 사용자가 자가 책임으로 하는 부분입니다

문젠 최저한도로 윈도 내장 탐색기등의 소프트는 저런 기능이 존재하는 이상 260자 제한에 안 걸려야 하는데, 안 된다는점이죠 (저럴바엔 왜 기능을 만든건지)

drachen 2022-02

오래된 API를 쓰지말라고 해도 계속 쓰고, 과거에 만들어진 프로그램이 계속 돌아가고 있는데 현실입니다.

또한 새로 만들어지는 프로그램 역시 그런 과거의 제약을 무시하지 못하기 때문에 일부러 예전처럼 만들기도 합니다.

탐색기도 결국 그런 제약에 맞춰서 만들어가는거죠.


애플처럼 다 뒤집어 앞고 호환 안되면 새로 사라고 하면 되는게 아니니까요.

대다수를 위해서 과거의 호환성을 유지하는거니까
반대로 필요한 사람은 여타 유틸리티를 쓰면 되는 겁니다.

dateno1 2022-02

그러니까 기능이 기본값 활성화가 아니니 모든건 사용자가 원해서 자가 책임으로 활성화하는겁니다

켠다음 데이터 손상등이 일어나도 결국은 사용자 책임입니다 (이로 인해 책임지는게 문제된다면 애초에 저런 옵션자체가 없어야 합니다)

딱히 탐색기등이 저런 제약에 안 메인다고 동영상 플레이어같은게 망가지거나 할일은 없습니다 (기컷해야 긴 경로의 파일 열떄 파일 없다고 뜨는정도겠죠)

애플처럼 하란건 아니지만, 최저한도로 옵션을 켜면 레지를 읽어서 내장엡도 거기 맞추어서 같이 사항이 변경되는식으로 만들었어야 한다는겁니다 (개발 부서가 따로 있는건 알겠지만, 하나의 상품의 기능이 완전히 따로 노는건 문제가 있다고 봅니다)

저 옵션이 추가된지가 언제인데 아직도 이런식인지 모르겠네요 (그리고 아무리 하위 호환성이 중요해도 9x시절에 나온 api를 아직도 호환시키기 위해 노력하는건 너무 과하다고 봅니다)

거기다 호환성 중시한다는 윈도의 Hi-DPI 호환성은 리눅스보다도 못한 꼴찌입니다 (심지어는 윈도 자체UI조차 비율 제대로 처리 못해서 레이아웃 깨지거나 합니다) (애초에 고 해상도 쓰는걸 시험하는지 설계하는지 궁금한게 4,5k 모니터 쓴다고 모니터 해상도에 맞는 해상도 이미지 파일에 우클릭해서 배경 그림 지정 시도하니 변환 실패하는지 검은 배경으로 바뀌어서 이미지 뷰어로 열어서 지정하니 정상적으로 될 정도입니다)