Linux 장치 경로를 Windows 드라이브 이름과 일치시키는 방법은 무엇입니까?

StackOverflow https://stackoverflow.com/questions/18959

  •  09-06-2019
  •  | 
  •  

문제

저는 어떤 단계에서 Linux 환경에서 낮은 수준의 디스크 작업을 수행하는 애플리케이션을 작성하고 있습니다.앱은 실제로 두 부분으로 구성됩니다. 하나는 Windows에서 실행되어 사용자와 상호 작용하고 다른 하나는 LiveCD에서 실행되는 Linux 부분입니다.사용자가 Windows 드라이브 문자를 선택하면 Linux 부분이 해당 파티션으로 작업을 수행합니다.문제는 Windows 드라이브 문자(예: C:)와 Linux 장치 이름(예: /dev/sda1) 간에 일치하는 항목을 찾는 것입니다.이것은 내가 추악하다고 평가하는 현재 솔루션입니다.

  • 파티션 정보를 저장합니다(예:드라이브 문자, 블록 수, 드라이브 일련 번호 등)을 Windows의 미리 정의된 장소(예:시스템 파티션의 루트).

  • /proc/partitions에서 파티션 목록을 읽습니다.전체 디스크가 아닌 SCSI 또는 IDE 하드 드라이브의 메이저 번호와 이를 실제 파티션으로 식별하는 마이너 번호가 있는 파티션만 가져옵니다.

  • ntfs 또는 vfat 파일 시스템을 사용하여 각각을 마운트해 보십시오.탑재된 파티션에 Windows 앱에서 저장한 정보가 포함되어 있는지 확인하세요.

  • Windows 앱에서 작성한 필수 정보를 찾은 후 실제 일치를 확인합니다./proc/partitions에서 발견된 각 파티션에 대해 드라이브 일련 번호(HDIO_GET_IDENTITY syscall을 통해), 블록 수(/proc/partitions에서) 및 드라이브 오프셋(/sys/blocks/drive_path/partition_name/start)을 획득하고 이를 Windows와 비교합니다. 정보 및 이것이 일치하는 경우 - Linux 장치 이름과 함께 Windows 드라이브 문자를 저장하십시오.

이 계획에는 몇 가지 문제가 있습니다.

  • 이것은 추악합니다.Windows에서 데이터를 쓴 다음 Linux에서 읽는 것은 테스트를 악몽으로 만듭니다.

  • Linux 장치 메이저 번호는 IDE 또는 SCSI 장치하고만 비교됩니다.이는 아마도 실패할 것입니다.USB 또는 FireWire 디스크에.이러한 유형의 디스크를 추가하는 것은 가능하지만 알려진 가능한 장치의 하위 집합으로만 앱을 제한하는 것은 다소 나쁜 생각인 것 같습니다.

  • HDIO_GET_IDENTITY는 IDE 및 SATA 드라이브에서만 작동하는 것 같습니다.

  • /sys/block hack은 IDE 또는 SATA 드라이브 이외의 드라이브에서는 작동하지 않을 수 있습니다.

이 스키마를 개선하는 방법에 대한 아이디어가 있습니까?아마도 Windows 앱에 모든 데이터를 쓰지 않고 Windows 이름을 결정하는 또 다른 방법이 있을까요?

추신앱 언어는 C++입니다.나는 이것을 바꿀 수 없다.

도움이 되었습니까?

해결책

파티션에는 연관된 UUID가 있습니다.Windows에서는 이를 찾는 방법을 모르지만 Linux에서는 다음을 사용하여 각 파티션의 UUID를 찾을 수 있습니다.

sudo vol_id -u 장치(예:/dev/sda1)

Windows에 동등한 기능이 있는 경우 선택한 파티션에 대해 UUID를 저장한 다음 Linux에서 알려진 모든 파티션을 반복하여 UUID를 일치시킬 수 있습니다.

편집하다: 이는 Linux에만 해당될 수 있으며 특히 드라이브의 메타데이터를 읽는 대신 무언가에서 이를 생성하는 volid 유틸리티일 수 있습니다.그렇긴 하지만, volid의 소스를 얻고 그것이 무엇을 하는지 확인하는 것을 막을 수는 없습니다.

다른 팁

파티션에는 UUID가 연결되어 있습니다.

이에 대한 나의 지식은 매우 얕지만, 전 세계 99%가 여전히 고수하고 있는 구식 MBR 형식이 아니라 GPT(Guid Partition Table) 파티션으로 포맷된 디스크에만 해당된다고 생각했습니다.

이것에 대한 나의 지식은 매우 얕지 만, 세계의 99%가 여전히 붙어있는 구식 MBR 형식보다는 GPT (Guid Partition Table) 파티션과 함께 형식의 디스크에 대해서만 사실이라고 생각 했습니까?

Linux 사용자의 진부한 표현처럼 들리지는 않지만 저에게는 효과적입니다.NTFS 파티션과 함께 사용하는데 아무런 문제가 없었습니다.내 편집에서 말했듯이 vol_id가 자체적으로 생성할 수 있습니다.만약 그렇다면 특정 파티션 형식에 의존하지 않을 것이며 이는 부풀어오르게 될 것입니다.

파티션에는 연관된 UUID가 있습니다.Windows에서는 이를 찾는 방법을 모르지만 Linux에서는 다음을 사용하여 각 파티션의 UUID를 찾을 수 있습니다.

sudo vol_id -u 장치(예:/dev/sda1)

Windows에 동등한 기능이 있는 경우 선택한 파티션에 대해 UUID를 저장한 다음 Linux에서 알려진 모든 파티션을 반복하여 UUID를 일치시킬 수 있습니다.

좋은 지적이군요. 감사합니다!vol_id(udev tarball의 일부) 소스를 살펴본 결과 FAT(32) 및 NTFS의 경우 파티션의 미리 정의된 위치에서 읽은 볼륨 일련 번호를 사용하여 UUUD를 생성하는 것 같습니다.나는 fat32와 ntfs 외에는 아무것도 기대하지 않기 때문에 이 정보를 파티션 식별자로 사용하는 것을 고려합니다.

어떤 방식으로든 드라이브를 표시해야 합니다(예:파일 쓰기 등) 또는 해당 특정 드라이브에만 연관된 식별자를 찾으십시오.

실제로 Windows를 실행하지 않고 Windows가 특정 드라이브 파티션에 어떤 문자를 할당하는지 파악하는 것은 매우 어렵고 거의 불가능합니다.이는 Windows가 실행되는 드라이브를 항상 C:와 연결하기 때문입니다.둘 이상의 운영 체제가 설치되어 있는 경우 어떤 드라이브든 가능합니다.또한 Windows에서는 특정 파티션에 대해 먼저 시도할 드라이브 문자를 선택할 수 있으므로 추가 문제가 발생합니다.

Window/Linux 혼합 솔루션을 시도하는 것보다 Linux 내에서 GUI 작업을 수행하는 것이 훨씬 쉬울 것입니다.나는 이런 식으로 시도하지 말라고 말하는 것이 아닙니다. 내가 말하고자 하는 것은 이 접근 방식에는 매우 많은 함정이 있을 수 있다는 것입니다.나는 그들 모두에 대해 알지도 못한다고 확신합니다.

또 다른 옵션은 Windows 내부에서 Linux 부분을 실제로 수행할 수 있는지 확인하는 것입니다.당신이 매우 훌륭한 Windows 프로그래머라면 실제로 원시 파일 시스템에 액세스할 수 있습니다.이 접근 방식에는 아마도 많은 함정이 있을 것입니다. 왜냐하면 이 모든 것이 작동하는 동안 Windows가 실행되기 때문입니다.

다시 한 번 말씀드리지만, 가능하다면 Linux 내에서 모든 작업을 수행할 수 있는지 확인하겠습니다.장기적으로 보면 훨씬 더 간단합니다.

Windows에서는 Linux의 UUID와 일치하는 "NTFS 볼륨 일련 번호"를 읽을 수 있습니다.

"NTFS Volume Serial"을 얻을 가능성 윈도우:

  • XP 이후 명령줄: fsutil.exe fsinfo ntfsinfo C:

  • C++에서

    HANDLE fileHandle = CreateFile(L"\\\\.\\C:", // or use syntax "\\?\Volume{GUID}" 
                               GENERIC_READ,
                               FILE_SHARE_READ|FILE_SHARE_WRITE,
                               NULL,
                               OPEN_EXISTING,
                               NULL,
                               NULL);
DWORD i;
NTFS_VOLUME_DATA_BUFFER ntfsInfo;
DeviceIoControl(fileHandle, 
                FSCTL_GET_NTFS_VOLUME_DATA, 
                NULL, 
                0, 
                &ntfsInfo,
                sizeof(ntfsInfo), 
                &i, 
                NULL));
cout << "UUID is " << std::hex << ntfsInfo.VolumeSerialNumber.HighPart << std::hex << ntfsInfo.VolumeSerialNumber.LowPart << endl;

UUID를 얻을 가능성 리눅스:

  • ls -l /dev/disk/by-uuid
  • ls -l /dev/disk/by-label
  • blkid /dev/sda1
라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top