Linux 및 macOS에서 "ls"가 동일한 파일에 대해 다른 소유자(uid)를 표시하는 이유는 무엇입니까?

Linux 및 macOS에서 "ls"가 동일한 파일에 대해 다른 소유자(uid)를 표시하는 이유는 무엇입니까?

복사본이 정확한지 확인하기 위해 macOS를 사용하여 일부 파일을 HFS+에 복사했습니다. macOS에 따르면 복사된 파일의 소유자는 501 입니다 ls -han.

그런 다음 HFS+ USB 스틱을 Ubuntu에 연결했는데, 그에 따르면 파일 소유자는 1000명입니다 ls -han. 왜?

그런 다음 Ubuntu에서 소유한 501개 파일 중 하나를 동일한 HFS+ 볼륨으로 복사해 보았습니다 cp -a.

macOS는 이제 ls새 파일을 사용자 1000이 소유한 것으로 취급합니다...

정말? 이해가 안 돼요. 소유자의 사용자 ID도 보존하지 않는 경우 해당 옵션을 사용하는 cp이유는 무엇입니까 ? -a내가 놓친 게 무엇입니까?

고쳐 쓰다:명확히 하자면, 제 생각에는 HFS가 기본적으로 Unix 파일 권한을 지원하고 "그냥 작동"해야 한다는 사실에서 혼란이 발생한다고 생각합니다.


나는 최근에 cps가 preserve=timestamps실제로 타임스탬프를 보존하지 않는다는 것을 알게 되었습니다(생성 날짜가 재설정됨). 이제 소유권이 유지되지 않는다고 믿습니까 preserve=ownership?

답변1

~에서hfsplus이 모듈에 대한 Linux 커널 문서:

설치 옵션

uid=n,gid=n

초기화되지 않은 권한 구조가 있는 파일 시스템의 모든 파일을 소유하는 사용자/그룹을 지정합니다. 기본값: 설치 프로세스의 사용자/그룹 ID입니다.

501은 최신 macOS의 일반 사용자를 위한 첫 번째 기본 UID입니다.

따라서 macOS는 일부 파일에 대한 "권한 구조"를 초기화하지 않는 것 같습니다. 반품,Apple 기술 노트 #1150소유자 ID 저장에 추가적인 문제가 있습니다.

소유자 ID

파일 또는 폴더 소유자의 Mac OS X 사용자 ID입니다. 10.3 이전의 Mac OS X 버전에서는 사용자 ID 99를 현재 콘솔에 로그인한 사용자의 사용자 ID로 처리했습니다. 콘솔에 로그인한 사용자가 없으면 사용자 ID 99는 사용자 ID 0(루트)으로 처리됩니다. Mac OS X 버전 10.3은 사용자 ID 99를 호출 프로세스의 사용자 ID로 처리합니다(사실상 모든 사람이 동시에 소유하게 됩니다). 이러한 대체는 런타임에 발생합니다. 디스크의 실제 사용자 ID는 변경되지 않습니다.

그 다음에:

노트:

fileMode 필드의 S_IFMT 필드(상위 4비트)가 0인 경우 Mac OS X에서는 권한 구조가 초기화되지 않은 것으로 가정하고 내부적으로 모든 필드에 대해 기본값을 사용합니다. 기본 사용자 및 그룹 ID는 99이지만 볼륨을 마운트할 때 변경할 수 있습니다. 이 기본 소유자 ID는 위에서 설명한 대로 대체됩니다.

이는 Mac OS 8 및 9에서 생성된 파일이나 권한 필드를 0으로 설정하는 다른 구현에서 해당 파일에 대해 소유권 무시 옵션이 비활성화된 경우에도 해당 파일에 대해 소유권 무시 옵션이 활성화된 것처럼 동작한다는 의미입니다. 전체 볼륨.

여기에 언급된 S_IFMT는 16비트 값의 상위 4비트이며 Unix 스타일 권한 비트(3x 읽기/쓰기/실행 및 setuid/setgid/sticky 비트)를 저장하는 데 사용됩니다. 일반 파일에서는 상위 4비트를 0이 아닌 특정 값( )으로 설정해야 합니다 S_IFREG. 그렇지 않으면 위에서 설명한 이전 버전과의 호환성 메커니즘이 시작됩니다.

HFS+ 파일 시스템의 구조는 때때로 파일 소유권을 "빠르고 느슨하게" 처리할 가능성을 열어주며, 결과에 따르면 macOS가 어떤 경우에는 정확히 그렇게 하는 것으로 보입니다.

이동식 미디어의 경우 미디어에 파일을 쓰는 시스템이 파일을 읽는 시스템과 다를 수 있고 두 시스템의 UID 매핑이 완전히 달라 불편을 끼칠 수 있으므로 macOS에서 "소유권 무시" 옵션을 자동으로 활성화하는 것이 합리적입니다. 사용자에게.

따라서 이는 macOS가 이동식 미디어에서 사용자 친화적이 되도록 노력하고 이동식 미디어에 대한 사용자의 물리적 소유권이 그 안에 있는 데이터의 소유권 증명과 동일하다고 가정하는 것일 수 있습니다.

Ubuntu의 첫 번째 일반 사용자 계정은 UID 1000으로 생성되며, 이는 분명히 HFS+ 볼륨을 Ubuntu에 마운트하는 계정입니다.

Linux에서 생성된 파일은 macOS에서 UID 1000을 유지하므로 이는 Linux가~ 할 것이다HFS+ "권한 구조"를 파일 소유자 UID로 채우고 macOS가 이를 읽으면 예상대로 작동합니다.


클래식 POSIX 타임스탬프는 다음과 같습니다.

  • ctime= 마지막 상태/메타데이터 변경 시간
  • mtime= 콘텐츠가 마지막으로 수정된 시간
  • atime= 마지막 액세스 시간.

생성 시간( crtime또는출생 시간)는 그중 하나가 아닙니다. 파일 시스템은 생성 시간을 지원할 수도 지원하지 않을 수도 있으며 정확한 의미는 파일 시스템 유형 및 Unix 스타일 운영 체제에 따라 달라질 수 있습니다.

crtime일부 파일 시스템 드라이버는 내부적으로 생성 시간 할당을 처리하며 나중에 파일 시간을 수정하는 것은 전혀 불가능합니다 . 이러한 파일 시스템에서는 실수로 백업에서 삭제하고 복원한 파일의 클래식 시간 ctimemtime복원 시간이 있을 수 있지만 생성 시간은 이제 파일이 더 이상 존재하지 않으므로 백업 시간부터 복원까지의 시간을 반영합니다.원래의, 비록 그것이그것의 정확한 사본.

파일을 복사할 때 분명히새 파일 만들기: 복사 작업에서 "생성 시간을 보존한다"는 생각은 모순입니다.

파일 시스템 자체는 파일이 생성된 시기를 추적할 수 있습니다.문서, 그러나 이는 생성 시간과 반드시 ​​동일하지는 않습니다.파일의 데이터. 후자를 추적하려면 일반적으로 데이터가 생성된 시간에 대한 메타데이터 필드를 포함할 수 있는 버전 제어 시스템이나 파일 형식이 필요하며 해당 데이터 형식을 사용하는 모든 애플리케이션은 "콘텐츠"의 의미에 동의해야 합니다. ". 데이터 생성 시간"을 입력하지 않으면 의미가 없습니다.

관련 정보