Removendo arquivos e variantes do DS_Store?

3

Estou executando um servidor LTS Ubuntu 10.04.1. Freqüentemente abro arquivos usando AFP do meu Mac. Inevitavelmente, isso criou arquivos .DS_Store no servidor (embora, por alguma razão, eles sejam denominados :2eDS_Store . No entanto, ele também cria variantes nos arquivos DS_Store. Essas variantes geralmente são nomeadas de forma semelhante a outros arquivos nesse diretório.

~$ ls
total 60K
-rw-r--r--  1 tarakhovsky  16K 2010-11-30 18:28 :2eDS_Store
drwx--S---  4 tarakhovsky 4.0K 2010-11-08 13:58 :2eTemporaryItems/
lrwxrwxrwx  1 tarakhovsky   15 2010-10-19 17:44 bigdisk -> /media/bigdisk//
...
drwxr-xr-x  3 tarakhovsky 4.0K 2010-11-03 18:24 Temporary Items/
drwxr-xr-x  3 tarakhovsky 4.0K 2010-11-30 01:34 tmp/
...

Desativei a criação de arquivos DS_Store usando:

defaults write com.apple.desktopservices DSDontWriteNetworkStores true

Espero que isso não continue ocorrendo, mas eu realmente quero me livrar de todas as variantes existentes dos arquivos DS_Store que já estão no servidor. Alguma idéia de por que essas variantes estão sendo criadas e como posso me livrar de todas elas?

    
por Ron Gejman 01.12.2010 / 16:40

7 respostas

4

O prefixo: 2e parece ser um efeito colateral da configuração padrão do serviço netatalk que não permite o uso de dotfiles; para evitar isso (ou seja, os nomes dos arquivos aparecem no servidor como .DS_Store etc), adicione options:usedots a cada compartilhamento em /etc/netatalk/AppleVolumes.default (consulte esta pergunta anterior e o documentação do netatalk ).

Isso não livrará os arquivos ": 2e" existentes ou evitará novos "." Quando os arquivos são criados, basta criar novos arquivos com nomes mais limpos (e torná-los invisíveis). A configuração DSDontWriteNetworkStores que você fez deve impedir que novos arquivos .DS_Store sejam criados, mas não impedirá os arquivos .TemporaryItems, .Trashes, ._ * (esses são arquivos AppleDouble que contêm recursos forks e metadados não padrão), etc. Eu não sei de nenhuma maneira de impedir que isso seja criado, você só pode limpá-los depois (e esperar que eles não tenham nada de importante neles - isso nem sempre é uma suposição segura).

Eu encontrei um script de Christian Imhorst para excluir vários desses arquivos no servidor. A codificação de caracteres em seu site é um pouco confusa, então vou incluir uma versão limpa (e ligeiramente modificada ...) aqui. Eu adicionei um pouco à lista de nomes de arquivos para excluir; Sinta-se à vontade para editar a lista de matar a gosto. Mas CERTIFIQUE-SE DE QUE VOCÊ TEM UM BACKUP ANTES DE EXECUTAR ISTO, pois qualquer script que inclua os caracteres "rm -rf" deve ser considerado como potencialmente perigoso.

#!/bin/bash
# Script:       sauber
# Object:       Cleans up your Linux file system after a 
#                   session with AppleTalk and Finder.
# Etymologie:   sauber means clean in German
# Author:       originally by Christian Imhorst [http://www.datenteiler.de/what-is-2eds_store/]
#                   modified by Gordon Davisson

# Test number of arguments here
if (( $# < 1 )) ; then
    echo >&2
    echo "We need an argument here." >&2
    echo "Usage:   ./sauber [Directory]" >&2
    echo "Example: ./sauber /home/christian"  >&2
    echo >&2
    exit 1
elif [[ ! -d "$1" ]] ; then
    echo "$1 is not a directory" >&2
    exit 1
fi

find "$1" \( -iname ':2eDS_Store' \
    -o -iname '.DS_Store' \
    -o -iname '.AppleDouble' \
    -o -iname 'Network Trash Folder' \
    -o -iname 'Temporary Items' \
    -o -iname ':2eTemporary Items' \
    -o -iname '.Temporary Items' \
    -o -iname ':2elocalized' \
    -o -iname '.localized' \
    -o -iname ':2e_*' \
    -o -iname '._*' \) -exec rm -rf {} \;
    
por 01.12.2010 / 22:31
2

Eu sei que essa é uma pergunta muito antiga - mas depois de fazer o upgrade para o Lion, recuperei esse problema. Acabei de instalar BlueHarvest e isso parece resolver o meu problema. Ele remove os arquivos indesejados no meu servidor Linux.

    
por 29.03.2012 / 17:42
1

Apenas um palpite aqui, mas 0x2e é hexadecimal para 46, que é ASCII para o caractere de período . . Eu suponho que os arquivos .DS_Store estão sendo renomeados de tal maneira que eles não colidam com a convenção de nomenclatura do Linux de que qualquer coisa que comece com um ponto é um arquivo oculto. Quanto ao que mecanismo está realmente fazendo isso, eu não sei; mas isso explica o "2e".

    
por 01.12.2010 / 17:23
0

Não sei por que eles são chamados: 2e_something em vez de .DS_Store, mas mesmo assim, TemporaryItems são criados por aplicativos Carbon (que é a antiga camada de compatibilidade do MacOS 9 ainda usada por alguns programas, ex. MS-Office) e não pode se livrar deles, AFAIK, mas eles são seguros para excluir.

O sistema os cria em primeiro lugar, porque o MacOS não pode usar atributos estendidos via Samba, mesmo se o FS subjacente os suportasse, então ele armazena coisas como garfos de recursos, rótulos de pastas etc. em arquivos ocultos.

Estes são um problema real se você também usa outros sistemas além do MacOS para acessar os arquivos porque eles não sabem sobre este emparelhamento e se você move, renomeia ou apaga arquivos, você acaba com muitos arquivos ._xxx órfãos.

    
por 01.12.2010 / 17:03
0

: 2E é provavelmente uma variante de% 2E que se traduz em a. (período) por link

    
por 01.12.2010 / 17:21
0

Eu não recomendaria a exclusão dos arquivos de ponto, pois isso pode causar problemas em alguns dos aplicativos que ainda usam forks de recursos (além disso, a maioria deles será recriada de qualquer maneira). Você também pode ver arquivos que começam com ._ e esses arquivos são a bifurcação de recurso do arquivo de uma conexão do Samba. Temos esses arquivos em alguns de nossos servidores e no final decidimos que não valeria a pena limpá-los todas as noites devido à potencial perda de dados.

    
por 01.12.2010 / 19:36
-1

Você deve conseguir encontrar todas as variantes da pasta usando:

find ./ -regex '/:2eDS_Store$' | xargs echo

Isso não excluirá os arquivos, mas você deve verificar os resultados primeiro e não confiar em mim, cego:)

    
por 01.12.2010 / 17:33