먼저 두 가지 매우 다른 것을 구별하고 싶습니다.
- 어떻게 독점의 구현
convert.exeWindows에서이 FAT32와 NTFS 사이에서 적절한 파일 시스템 변환을 담당한다.
- 일반적으로 사용 가능한 디스크 공간의 2 배나 두 파일 시스템간에 상호 운용 가능한 메타 데이터 또는 문제를 사소하게 만드는 다른 멋진 요소없이 두 파일 시스템 간 변환 문제에 어떻게 접근 할 수 있습니까?
첫 번째로, 우리는 대부분 Windows의 소스에 액세스하는 사람은 NDA에 서명해야하므로 Microsoft가 그 정보를 공개 할 것을 자비합니다. Microsoft의 법률 팀에서 승인 한 경우에만 릴리스됩니다. 물론,이 질문을 읽는 누군가가 유출 된 Windows 소스의 불법 사본을 가져 와서 코드에서 알아낼 수는 있지만 합법적 인 회색 영역입니다.
따라서 답변이 없기 때문에 첫 번째 질문에 대한 답변을 제공하지 않습니다.
그러나 두 번째 질문에 대답하겠습니다.
파일 시스템의 역사에는 OS를 지우거나 다시 설치하거나 두 번째 디스크를 사용하지 않고 한 파일 시스템에서 다른 파일 시스템으로 업그레이드하려는 많은 경우가 있습니다. 몇 가지 예를 들면 다음과 같습니다.
- 2017 년에 Apple iOS 기기를 iOS 10.3으로 업그레이드하는 모든 사람 은 iDevice의 내장 NAND에서 HFS +에서 APFS로 전체 파일 시스템 업그레이드를 받았습니다.
- 수년 동안 btrfs는 btrfs-convert 도구를 사용하여 ext4에서 btrfs로 파일 시스템 업그레이드를 지원했습니다 .
오픈 소스 fstransform 프로그램은 여러 가지 파일 시스템 (일부주의 사항 및 제한 사항) 을 변환하기위한 것으로, 대부분의 일반적인 Linux 파일 시스템과 인상적인 NTFS를 포함합니다! 그러나 다른 많은 파일 시스템을 지원하더라도 FAT32는 아직 지원하지 않습니다.
C ++ 코드를 읽으면 원본 파일 시스템 작성자가 소스 파일이나 대상 파일 시스템에 의해 호환성이나 상호 운용성을 계획하거나 설계하지 않은 경우에도 이기종 파일 시스템 간 변환과 관련된 일반적인 알고리즘에 대해 가장 자세한 기술 지식을 제공 할 수 있습니다. !).
광범위한 과정에서 일반적인 프로세스는 다음과 같습니다.
- 현재 파일 시스템의 파일 / 디렉토리 트리를 걷습니다. 기존 파일 시스템 내의 새로운 일반 파일 에서 현재 파일 시스템의 파일 목록을 기반으로 FS 특정 파일 테이블 (파일, 디렉토리, 기호 링크, 권한 등)을 새 파일 시스템 형식으로 구성합니다. .
- 새 파일 시스템의 데이터 구조와 관련하여 이전 파일 시스템의 데이터 구조 및 내부 메타 데이터를 형식화하고 새 파일 테이블 내에서 포인터 (해당되는 경우 논리 디스크 블록 및 오프셋)를 업데이트하여 재 계산 된 파일을 가리 킵니다. / directory / permission 블록 ( "inodes"또는 "streams"와 같은 일반적인 개념을 사용하여 변환하는 파일 시스템에 따라 다름)
- 프로세스가 끝날 때, 새로운 파일 시스템의 메타 데이터로 원본 파일 시스템의 메타 데이터 (마법 번호 등을 사용하여 파일 시스템을 이전 파일 시스템 유형으로 식별)를 파괴적으로 덮어 쓰고 "슈퍼 블록"을 가리키는 적절한 맵을 생성합니다. "MFT"또는 파일 시스템 자체를 초기화하는 데 필요한 파일 시스템 별 데이터 구조
- 디스크 전역 파티션 테이블 (예 : MSDOS 형식 또는 GPT 형식)을 업데이트하여 필요한 경우 파티션에 포함 된 파일 시스템 유형을 암시하는 매직 번호를 업데이트하십시오 (참고 : 특정 파일 시스템은 동일한 매직 번호를 공유합니다. 일부 파일 시스템 드라이버는 매직 번호를 무시하고 파일 시스템의 실제 데이터 구조를 "프로브 (probe)"하여 해당 파티션에 지정된 파일 시스템의 인스턴스가 있는지 여부를 판별 할 수 있습니다.)
적어도 마지막 두 단계는 원 자성 이 아니라는 점에 주목할 가치가 있습니다.; 즉, NTFS, reiserfs, XFS, zfs 등과 같은 저널 파일 시스템의 일반적인 원 자성을 보장 할 수 없습니다. 시스템이 충돌하거나 전원이 꺼 지거나이 프로세스 중에 변환을 수행하는 사용자 공간 프로그램이 충돌하거나 중단 된 경우에도 파일 시스템은 데이터 복구 전문가가 데이터를 다시 가져 오거나 파일 시스템에 대한 온 전성을 복원해야합니다 (이전 또는 신규). 이러한 "파괴적인"작업 중에 기본 저장 매체는 본질적으로 이전 파일 시스템의 저널을 우회하는 프로세스로 인해 파일 시스템 저널에 의해 백업되지 않는 방식으로 중요한 데이터를 파괴적으로 덮어 씁니다 (하나에서 변경하기 위해). 다른 파일로 FS를 사용하면 이전 파일 시스템에 핵심 메타 데이터를 알 수없는 것으로 덮어 써서 "안전하게 죽 이도록"지시 할 수 없습니다.
반대로 데이터 쓰기 를 수행하여 일반 쓰기 를 수행하는 파일 시스템을 요청하는 것은 사실상 원자 적입니다. 전체 쓰기가 완료되거나 전혀 완료되지 않습니다 (저널 영역에 대한 불완전한 부분 쓰기는 롤백 될 수 있음) 시스템 BSOD 또는 커널 패닉 후 부팅시 fsck또는 chkdsk프로그램이 수행 하는 쓰기 도중에 시스템 충돌이 발생 합니다.)
전체 FS 변환은 매우 위험합니다. 많은 작업의 안전성이 보장되지 않기 때문에 BIOS 플래시 (모바일 장치에서 부팅 할 수없는 OS를 사용하여 영구적으로 브릭 킹 할 수있는 모바일 장치)만큼 위험합니다. 시간이 오래 걸리는 경향이 있기 때문에 사용자가 변환 중에 OS가 정지되고 전원을 껐다 켜거나 배터리가 부족한 배터리로 작동하는 장치를 사용한다고 생각할 가능성이 높습니다.
이 작업을 수행 할 수있는 방법에 더 많은 통찰력을위한 안전하고 두 파일 시스템의 알고 협력 설계 , 다른 하나 사이의 변환 (나는 그것을 이해했다, iOS의 HFS + APFS에 변환의 경우),이 매혹적인 talk 는 APFS에서 도대체 무슨 일이 일어나고 있는지 알아 내기 위해 법 의학적 접근법을 취합니다. 변환 문제를 직접 해결하지는 않지만 제공된 정보에서 변환에 대한 몇 가지 세부 정보를 유추 할 수 있습니다.
이것은 모두 당신의 정확한 원래 질문에 대한 확실한 대답을 찾지 못할 수도 있지만, 전체 FS 변환의 일반적인 프로세스에 대한 많은 지식을 제공하면 가능성이 무엇인지를 미스터리 할 수있는 충분한 단서를 제공해야한다고 생각합니다. 에 대한 프로세스입니다 convert.exe.
BTW, 나는 원래 "ReactOS가 이미이 툴을 구현했을 것이고 소스 코드를 볼 수있을 것입니다."라고 생각했습니다. - 아니 그들은 ReactOS에서 open.exe로 convert.exe를 구현하지 않았습니다. 시스템의 모든 사용자가 전혀 사용하지 않는 경우 독점 MS Windows 바이너리를 실행해야합니다. 그렇지 않으면 ReactOS 에서이 유틸리티를 제공하지 않는 것 같습니다.