Por que `ls` no Linux e no macOS mostra diferentes proprietários (uid) para o mesmo arquivo?

Da documentação do kernel Linux para o hfsplusmódulo :

Opções de montagem

uid=n, gid=n

Especifica o usuário/grupo que possui todos os arquivos no sistema de arquivos que possuem estruturas de permissões não inicializadas. Padrão: ID do usuário/grupo do processo de montagem.

501 é o UID padrão do primeiro usuário regular no macOS moderno.

Portanto, aparentemente o macOS não inicializa "estruturas de permissões" para alguns arquivos. Além disso, o Apple Technote #1150 indica que o armazenamento do ID do proprietário tem um problema adicional:

ID do proprietário

O ID de usuário do Mac OS X do proprietário do arquivo ou pasta. As versões do Mac OS X anteriores à 10.3 tratam o ID do usuário 99 como se fosse o ID do usuário atualmente conectado ao console. Se nenhum usuário estiver conectado ao console, o ID do usuário 99 será tratado como o ID do usuário 0 (root). O Mac OS X versão 10.3 trata o ID do usuário 99 como se fosse o ID do usuário do processo que está fazendo a chamada (na verdade, tornando-o propriedade de todos simultaneamente). Essas substituições acontecem em tempo de execução. O ID do usuário real no disco não é alterado.

e depois:

Observação:

Se o campo S_IFMT (4 bits superiores) do campo fileMode for zero, o Mac OS X assumirá que a estrutura de permissões não foi inicializada e usará internamente valores padrão para todos os campos. Os IDs padrão de usuário e grupo são 99, mas podem ser alterados no momento em que o volume é montado. Este ID de proprietário padrão está então sujeito a substituição conforme descrito acima.

Isso significa que os arquivos criados pelo Mac OS 8 e 9, ou qualquer outra implementação que defina os campos de permissões como zeros, se comportarão como se a opção "ignorar propriedade" estivesse habilitada para esses arquivos, mesmo que "ignorar propriedade" estivesse desabilitada para o volume como um todo.

S_IFMT mencionado aqui são os 4 bits mais altos do valor de 16 bits usado para armazenar os bits de permissão no estilo Unix: 3x leitura/gravação/execução e os bits setuid/setgid/sticky. Um arquivo normal precisa que os 4 bits mais altos sejam definidos para um valor específico diferente de zero ( S_IFREG) ou então o mecanismo de compatibilidade com versões anteriores descrito acima entrará em ação.

A estrutura do sistema de arquivos HFS + abre claramente a possibilidade de, às vezes, brincar de forma "rápida e solta" com as propriedades dos arquivos, e seus resultados indicam que o macOS parece fazer exatamente isso em algumas situações.

Para mídia removível, faria certo sentido que o macOS habilitasse automaticamente a opção "ignorar propriedade", pois o sistema que grava os arquivos na mídia pode não ser o mesmo que o lerá, e os dois os sistemas podem ter mapeamentos UID totalmente diferentes, resultando em inconveniência para o usuário.

Portanto, isso pode ser apenas o macOS tentando ser amigável em mídia removível e assumindo que a posse física da mídia removível pelo usuário é equivalente a uma prova de propriedade dos dados contidos nela.

A primeira conta de usuário regular do Ubuntu é criada com UID 1000, e aparentemente essa é a conta que você montou o volume HFS + no Ubuntu.

Como os arquivos criados pelo Linux mantêm seu UID 1000 no macOS, isso indica que o Linux preencherá as "estruturas de permissões" HFS + com os UIDs do proprietário do arquivo e, assim que o macOS os ler, eles funcionarão conforme o esperado.

Os carimbos de data/hora POSIX clássicos são:

• ctime= hora da última alteração de status/metadados
• mtime= hora da última modificação do conteúdo
• atime= hora do último acesso.

A hora da criação ( crtimeou hora do nascimento ) não é uma delas. Um sistema de arquivos pode ou não suportar tempos de criação, e sua semântica exata pode variar entre os tipos de sistema de arquivos e os sistemas operacionais estilo Unix.

Alguns drivers de sistema de arquivos atribuem o horário de criação internamente e tornam totalmente impossível modificar o crtimearquivo posteriormente: em tal sistema de arquivos, um arquivo que foi acidentalmente excluído e restaurado de um backup pode ter seu clássico ctimee mtimerestaurado, mas o horário de criação será refletem o momento da restauração do backup, já que o arquivo não é mais o original , embora possa ser uma cópia exata dele .

Ao copiar um arquivo, você simplesmente cria um novo arquivo : a ideia de "preservar o tempo de criação" em uma operação de cópia é um oxímoro.

Um sistema de arquivos por si só pode rastrear o horário de criação de um arquivo , mas isso não é necessariamente o mesmo que o horário de criação dos dados dentro do arquivo . Se você deseja rastrear o último, geralmente precisa de um sistema de controle de versão ou de um formato de arquivo que possa incluir um campo de metadados no momento da criação dos dados... e todos os aplicativos que usam esse formato de dados devem concordar com a semântica do que o " tempo de criação de dados" significa, ou então perderá o sentido.