Posso archiviare le fork di risorse OS X in una condivisione Samba ovunque * altro * rispetto ai file dotbar?


15

Le fork di risorse OS X sono flussi alternativi di dati allegati a file regolari. Possono contenere l'icona personalizzata del file, l'etichetta colorata, le parole chiave o qualsiasi altro metadato impostato dall'utente o dalle applicazioni.

Sono supportate nativamente dal file system HFS + di OS X, ma ogni volta che OS X monta un altro file system, sia esso locale (FAT32) o remoto (NFS, SMB) sono memorizzati nei cosiddetti file "dotbar": il fork delle risorse per il file regolare name.extè memorizzato in un altro file normale ma nascosto ._name.ext. (Non devono essere confusi con i .DS_Storefile, che memorizzano le impostazioni di visualizzazione di una directory, come l'icona rispetto alla vista a colonna o la posizione della sua finestra.)

Il problema con i ._file dotbar è che si tratta di veri e propri file regolari, nel filesystem di destinazione, con la stessa estensione del file originale, causando quindi il caos in diversi modi. Ad esempio, Ant e Maven vedranno ._MyClass.javaancora un altro file Java da compilare.

Vedo che OS X può essere configurato per archiviare fork di risorse in flussi denominati SMB e che Samba può essere configurato per archiviare flussi denominati in attributi estesi POSIX o, in alternativa, in una directory di deposito altrove .

Entrambe le soluzioni risolverebbero il problema dei file dotbar che inquinano il filesystem di destinazione, ma non riesco nemmeno a farlo funzionare.

 
xattr

Per prima cosa ho provato con xattr:

vfs objects = streams_xattr
kernel oplocks = no

Quest'ultima opzione è dovuta a questo errore . Ho detto a OS X di usarlo, facendo questo nella radice della condivisione, prima di montarlo:

touch .com.apple.smb.streams.on

Ma quando ho provato a copiare un file con Finder, ho riscontrato questo errore:

Il Finder non può completare l'operazione perché alcuni dati in "hello.java" non possono essere letti o scritti.
(Codice errore -36)

 
Deposito

Quindi ho provato con il deposito:

vfs objects = streams_depot

lasciando .com.apple.smb.streams.onnella radice della condivisione. Tentando di copiare lo stesso file con Finder, ho riscontrato un altro errore:

Impossibile completare l'operazione perché si è verificato un errore imprevisto
(codice errore -50)

 
Come posso far funzionare OS X con una di queste due opzioni? Il mio scopo è quello di ottenere quei cattivi ._dalle directory condivise.

Ho provato semplicemente a porre il veto ai file dotbar:

veto files = /._*/
delete veto files = yes

Ma ciò causa il fallimento di alcune applicazioni, ad esempio Mercurial quando eseguito da OS X su una condivisione SMB montata .

Sto usando OS X 10.9.5 come client; Samba 3.6.6 da Debian Wheezy come server.

Modifica: ecco la mia configurazione come richiesto:

[global]
    security = user
    invalid users = root
    workgroup = COMPANY_NAME
    encrypt passwords = true
    panic action = /usr/share/samba/panic-action %d
    syslog = yes
    syslog only = yes

    # PERFORMANCE TUNING
    socket options = TCP_NODELAY IPTOS_LOWDELAY SO_RCVBUF=131072 SO_SNDBUF=131072 SO_KEEPALIVE
    read raw = true
    write raw = true
    use sendfile = true
    min receivefile size = 16384
    aio read size = 16384
    aio write size = 16384
    max xmit = 131072
    getwd cache = true

    # DEFAULT OPTIONS FOR ALL SHARES
    writeable = true
    force group = company_group

    create mask = 664
    security mask = 664
    force create mode = 664
    force security mode = 664

    directory mask = 2775
    directory security mask = 2775
    force directory mode = 2775
    force directory security mode = 2775

    # solve problem where OS X clients remove mode 0100
    map archive = no

[homes]
    browseable = no

Hai provato a modificare la unix extensionsdirettiva nella [global]sessione per vedere se risolve il tuo caso? Puoi aggiornare la tua domanda con l'output del testparmcomando?
febbraio

@fgbreel Aggiunta della configurazione alla mia domanda. Non ho provato a cambiare le estensioni unix, perché è abilitato per impostazione predefinita (e ho bisogno di mappare collegamenti simbolici e cose simili). Pensi che dovrei disabilitarlo?
Tobia,

Sì, non ha senso :(
fgbreel

Risposte:


2

Sembra che potresti essere in grado di farlo con il nuovo modulo vfs_fruit , impilato con il modulo VFS vfs_streams_xattr .

Vedi, ad esempio, questo thread della mailing list . Hai bisogno di un filesystem sottostante che supporti gli attributi estesi e devi averlo montato con essi abilitati.

Tuttavia , secondo il wiki di Samba , questa è una nuova funzionalità di Samba 4.2, quindi dovrai aggiornare. (A partire da ora, anche Debian Sid [sperimentale] non ha ancora 4.2.)

Se non sei interessato ad abbandonare il pacchetto Debian e costruire una nuova versione di Samba (o aggiornare a Jessie e aspettare che il 4.2 venga mostrato in jessie-backport), puoi nascondere i file dot dai client.

Potresti avere due diverse condivisioni che puntano alla stessa directory, una delle quali nasconde i file ._, per esempio. Forse non ottimale, ma potrebbe essere praticabile.


0

Non so se sia possibile con le preferenze native del Mac, ma puoi usare uno strumento come Asepsis per aiutare con questo problema. Sposterà tutti gli escrementi di Mac nelle proprie cartelle.


L'ultima volta che ho controllato, Asepsis rimuove solo i .DS_Storefile, non i file "dotbar" ._*che causano la maggior parte dei problemi nelle condivisioni di rete
Tobia,

@Tobia: sollevi un buon punto. In quel caso, ho trovato anche BlueHarvest , ma non è gratuito. Sembra che BlueHarvest utilizzi il monitoraggio in tempo reale, mentre Asepsis utilizza la direzione passiva (tramite l'applicazione di patch a un file di sistema).
Blake Johnson,

Grazie. Ma aspetterò una soluzione dal lato Samba, poiché credo che sia solo una questione di configurazione.
Tobia,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.