A origem do .DS_Store (2006)

 (arno.org)
3 pontos por GN⁺ 2024-07-04 | 1 comentários | Compartilhar no WhatsApp
  • .DS_Store é a abreviação de Desktop Services Store, criada quando o Finder para Mac OS X foi refeito em 1999
  • Na época, a base de código do Finder tinha cerca de 8 anos, então até pequenas mudanças tinham alto custo e quebravam recursos aparentemente não relacionados, tornando necessária uma reescrita completa
  • O novo Finder separou a interface de usuário do backend, e o backend ficou responsável por enumeração de arquivos, monitoramento de alterações, posições de ícones e metadados como configurações de pastas
  • O backend do Finder se tornou candidato a uma API pública que também poderia ser usada fora do Finder e, junto com a possibilidade de renomear o Finder para “Desktop”, recebeu o nome Desktop Services
  • O .DS_Store originalmente deveria ser criado apenas ao alterar configurações de visualização ou posições de ícones, mas, por causa de um bug, muitas vezes era gerado simplesmente ao visitar uma pasta

O nascimento do nome Desktop Services Store

  • Em 1999, quando a Apple estava criando um novo Finder para o Mac OS X, a base de código do Finder existente tinha cerca de 8 anos
    • Alterações exigiam grande esforço de engenharia
    • Mudanças normalmente quebravam 2 ou 3 recursos aparentemente não relacionados
    • Foi decidido que o Finder para Mac OS X seria reescrito do zero
  • Durante a reescrita, a interface de usuário do Finder foi separada do backend de funcionalidades principais
    • Os nomes internos eram Finder_FE e Finder_BE, respectivamente
    • O backend era responsável por enumerar arquivos, monitorar mudanças no sistema de arquivos, processar metadados, posições de ícones e configurações de pastas
  • Como o backend do Finder também poderia ser útil fora do Finder, surgiu o plano de oferecê-lo algum dia como uma API pública
    • Com base na experiência anterior de nomear Icon Services e Navigation Services, foi escolhido o nome Desktop Services
    • Na época, também estava em análise a possibilidade de renomear o Finder para “Desktop”
    • .DS_Store vem de “Desktop Services Store”
    • O . inicial foi uma escolha para que o arquivo fosse tratado como invisível em sistemas operacionais Unix-like e no Mac OS

Condições de criação e impacto posterior

  • O nome poderia ter sido mais descritivo, mas, depois que já estava amplamente em uso, ficou difícil mudá-lo
  • O arquivo .DS_Store originalmente deveria ser criado apenas quando o usuário ajustasse as configurações de visualização de uma pasta ou definisse manualmente a posição dos ícones
    • Porém, devido a um bug não corrigido, o arquivo passou a ser criado em excesso
    • Na prática, fica quase garantido que um arquivo .DS_Store seja criado apenas ao visitar uma pasta
  • Finder_BE, ou seja, Desktop Services, também é usado fora do Finder
    • Navigation Services, isto é, as caixas de diálogo de abrir/salvar, também passou a usá-lo posteriormente
    • Nos lançamentos iniciais do Mac OS, Navigation Services não o usava
    • A Desktop Services API ainda não foi totalmente tornada pública

Leituras relacionadas

1 comentários

 
GN⁺ 2024-07-04
Opiniões no Hacker News

  • Além desse arquivo, também havia momentos de confusão por causa do conceito de fork no sistema de arquivos do Mac
    Aqui, fork não era fork(), mas uma estrutura em que um componente de dados e um componente de recursos existiam como um par dentro do sistema de arquivos; um era tratado como metadados, e o outro como o conteúdo do arquivo
    No Unix, os metadados ficavam no lado dos blocos de diretório/inode e não eram um formato vinculado exclusivamente ao arquivo, então estruturas como tar, cpio e zip precisavam representá-los separadamente
    Para implementar suporte a arquivos compatíveis com Mac no Unix, era preciso tratar o resource fork como dados de primeira classe, e o modo natural era colocar um arquivo como .file ao lado de cada arquivo
    Na época, os blocos de inode do UFS não conseguiam mapear todos os atributos do resource fork, e ele também continha coisas como ícones. Sistemas de arquivos mais modernos têm estruturas de blocos de diretório maiores, capazes de lidar melhor com esses dados

    • Acho que descrever como “um é metadados, o outro é conteúdo do arquivo” não é preciso para explicar o resource fork
      O mais correto é ver como dois conjuntos de conteúdo de arquivo: um era chamado data, e o outro, rsrc; no disco, ambos eram apenas fluxos de bytes
      Porém, o resource fork normalmente armazenava uma estrutura de pequenos pedaços de dados indexados por um código de tipo de 4 bytes e um ID inteiro de 2 bytes
      Aplicativos Mac 68K colocavam quase tudo no resource fork — código, menus, caixas de diálogo, imagens, ícones, strings etc. — e, se você copiasse um app antigo de Mac para um PC ou Unix sem conversão, ele parecia um arquivo vazio
      Por isso, para enviar apps de Mac pela rede, era preciso codificá-los em um único fluxo; no início eram usados BinHex .hqx ou MacBinary .bin, e depois arquivos Stuffit .sit
      O motivo de essa estrutura não caber bem em um inode é que seria, na prática, como enfiar um arquivo inteiro ali dentro. A estrutura do resource fork em si tinha um limite de 16 MB, mas, se fosse tratada como um fluxo de dados separado, podia ser tão grande quanto se quisesse
    • Lembro que o resource fork continha coisas que antigamente eram editadas com o ResEdit. Ícones, vários recursos de GUI, e também texto e ativos de tradução eram possíveis
      Por exemplo, plugins do Escape Velocity usavam tipos de recurso personalizados e podiam ser editados facilmente com um plugin do ResEdit
    • O NTFS também tem fluxos de dados alternativos (Alternate Data Streams), mas acho que quase não são usados
      https://en.wikipedia.org/wiki/NTFS#Alternate_data_stream_(AD...
    • Metadados de aplicativos, como os formatos de arquivo que um aplicativo pode abrir ou qual ícone usar quando corresponde ao creator code do aplicativo, eram armazenados no resource fork desse aplicativo, mas metadados de arquivos não eram armazenados no resource fork
      Tipo de arquivo, creator code, bloqueio, bits invisible e bozo etc. sempre eram armazenados no sistema de arquivos
      Por exemplo, veja a descrição do formato de disco MFS: https://wiki.osdev.org/MFS#File_Directory_Blocks
    • Criar CDs/DVDs de formato duplo por causa dos dados bifurcados era bem interessante. No começo era uma espécie de gambiarra, mas depois os softwares de gravação para Mac passaram a lidar com isso facilmente
      Fazer um DVD de boot para Mac também não era exatamente trivial

  • Lembro que antigamente havia uma forma de desativar a criação de .DS_Store, mas a Apple a removeu, e não entendo de jeito nenhum por que fez essa mudança
    Acabei escrevendo eu mesmo um programa que monitorava todo o sistema de arquivos e apagava .DS_Store assim que ele aparecia
    [0] https://github.com/slmjkdbtl/dskill

    • Dá para desativar em volumes de rede
      defaults write com.apple.desktopservices DSDontWriteNetworkStores -bool TRUE
      https://support.apple.com/en-us/102064
      Não me lembro de algum dia ter havido uma forma de desativar em volumes locais
    • A Apple realmente bagunçou tudo quando começou a criar arquivos iniciados por . na raiz do sistema de arquivos
      Depois que .DS_Store foi permitido, parece que ficou fácil para outros engenheiros aprovarem coisas como .fseventsd e .Spotlight-V100
      Nem sei dizer quantos sistemas de arquivos “contaminados” já vi por causa desses arquivos. Eram principalmente cartões SD ou pendrives USB, mas às vezes havia casos muito mais terríveis
      Normalmente, nessas situações, eu rodo rm -rf .DS_Store .Trashes ._.Trashes .fseventsd .Spotlight-V100 e ejeto rapidamente o drive antes que algo mais seja escrito
      Especialmente quando é preciso copiar dados de um disco em estado de degradação, a última coisa que você quer é que ele comece a indexar tudo e a gravar no disco
      Sério, isso deveria ter uma opção de configuração
    • find / -name ".DS_Store" -exec rm {} \; 2>/dev/null
      É só colocar isso em um script e adicionar ao crontab

  • .DS_Store parece um design realmente azarado. Tem um propósito e há várias formas de contornar, mas, na prática, acabou virando algo que espalha lixo de arquivo para 99% das pessoas que se deparam com ele
    Em termos de acabamento da experiência do usuário, não parece coisa da Apple
    Cresci usando System 7.5, OS X e Windows juntos, e o Mac tendia a não fazer você ver detalhes de implementação como arquivos ou formatos de arquivo desnecessários, ou “como o computador funciona internamente”
    Por isso, ver esse arquivo surgindo por toda parte me parece estranho, porque contraria muito meu modelo mental sobre o Mac

    • Quem vive apenas dentro do ecossistema Apple nunca vê arquivos .DS_Store, a menos que use o terminal
      O Finder agora não os mostra nem quando a exibição de arquivos ocultos está ativada
      Mas, ao compartilhar arquivos de um Mac com usuários de Windows, fica realmente feio, e acho que pode causar uma má primeira impressão em quem está pensando em migrar para o Mac
    • A qualidade de acabamento da Apple sempre esteve mais perto da superfície do que do interior

  • Não entendo por que precisa ficar na mesma pasta. O sistema operacional não poderia manter seu próprio pequeno banco de dados em algum lugar e referenciar cada caminho?

    • A intenção era fazer com que metadados, como rótulos de arquivos, se movessem junto com os arquivos independentemente do dispositivo em que o drive de rede fosse usado
    • Deixar dentro da pasta também tem a vantagem de ser apagado naturalmente junto quando a pasta é excluída

  • Concordo com a ideia de que “só deveria ser criado quando o usuário realmente ajusta as configurações de visualização ou define manualmente a posição dos ícones dentro da pasta”. Mas, na prática, só visitar uma pasta quase garante que um .DS_Store seja criado
    Essa é minha maior reclamação sobre o Finder
    É um recurso realmente ótimo poder personalizar de várias formas a aparência e o tamanho das janelas de pastas individuais, como no Finder do Classic Mac OS
    Mas basta passar pela mesma pasta numa janela de navegador e, mesmo sem mudar nada, a maior parte dessa personalização acaba sendo sobrescrita pelas configurações da janela de navegador
    Se vai quebrar tão facilmente, não faz sentido permitir uma personalização excelente
    Eu abro a pasta Applications com um atalho global, mas não adianta querer personalizar a aparência dessa janela. Cada vez que aperto o atalho, não sei o que vou ver, e ela fica sendo redefinida
    O motivo é que não há no Finder uma forma de definir uma configuração padrão de janela de navegador. Em vez disso, ele deixa as configurações atuais do navegador em cada pasta visitada, o que é realmente frustrante

    • Antes do Darwin, uma pasta aberta correspondia a uma janela, e também havia apenas um usuário, então essa abordagem funcionava bem
      Era muito bom — e dá saudade — ver a mesma janela aparecer na frente exatamente do jeito em que tinha sido deixada da última vez
    • Não é global, mas dentro do Finder dá para abrir a pasta Applications com cmd-shift-A e a pasta Utilities com cmd-shift-U

  • Como não sou usuário de Mac, sempre fico meio irritado quando um .tgz baixado de lugares como o GitHub vem cheio de .DS_Store
    O macOS provavelmente usa o GNU tar, então é bem surpreendente que não tenham modificado ou configurado para ignorar .DS_Store por padrão

    • Não é o padrão, mas dá para fazer isso
      Se você exportar COPYFILE_DISABLE=true, o tar pula os arquivos .DS_Store
    • A maioria dos utilitários Unix do Mac não foi especialmente mexida pela Apple; veio quase diretamente do FreeBSD

  • Vale mencionar que há uma forma de desativar por padrão a criação de arquivos .DS_Store ao navegar por volumes de rede. Caso contrário, só passear pelo Finder já altera o horário de modificação dos diretórios, e isso é péssimo
    https://old.reddit.com/r/MacOS/comments/lvju40/comment/gpc8i...

    • O macOS de hoje é traiçoeiro. Quando olhei pelo Finder se havia .DS_Store no volume de rede, parecia que não havia, mas, ao ir para o terminal, eles estavam lá de fato
      Agora não dá para confiar no recurso do Finder de mostrar arquivos ocultos. Em vez de mostrar todos os arquivos ocultos, ele mostra apenas os arquivos ocultos que o Finder julga que o usuário deveria se importar em ver
      Meu compartilhamento de rede é um Synology local, então não é um grande problema, mas no trabalho esses arquivos criavam uma situação bem bagunçada
    • Pessoalmente, faço usuários de Mac aplicarem essa configuração antes de receberem permissão de escrita em compartilhamentos de rede. Vejo isso como uma boa etiqueta de uso compartilhado básica
    • Se você administra Samba, também pode fazer uma configuração do Samba para simplesmente ignorar essas solicitações de criação

  • Também existem os arquivos com ponto e sublinhado (._). Há alguma forma de desativar para que esses arquivos não apareçam em compartilhamentos de rede?
    [0] https://superuser.com/questions/212896/is-there-any-way-to-p...

  • Felizmente, usando o gerenciador de arquivos Dired do Emacs, dá para fingir facilmente que esses arquivinhos incômodos e os arquivos gerados pela execução do LaTeX não existem
    (setq dired-omit-mode t
    dired-omit-files "^.+\\.\\(DS_Store\\|aux\\|bak\\|bbl\\|bcf\\|blg\\|dvi\\|ent\\|idx\\|ilg\\|ind\\|log\\|orig\\|out\\|pdf-view-restore\\|pdf#\\|reg\\|run.xml\\|synctex.gz\\|toc\\)$")