1. Problemi con caratteri speciali nei nomi dei file
Ci sono caratteri speciali nei nomi dei file? A seconda del filesystem in cui stai scrivendo questi file, potrebbero non permetterti di precedere i file con un punto ( .
) per esempio.
2. Problemi con i tempi di modifica rsync e webdav2
Mi sono imbattuto in questo post sul blog in cui viene descritto rsync
un problema con un problema durante la scrittura / il monitoraggio dei tempi di modifica dei file nelle directory box.com montate su webdav2.
Il problema si presenta così nel file system montato:
david@sydney:~/Pictures$ ls -l /mnt/box/bwca/08/09/IMG_3084.CR2
-rw-r--r-- 1 david david 12564061 Aug 14 16:08 /mnt/box/bwca/08/09/IMG_3084.CR2
david@sydney:~/Pictures$ ls -l 2012/08/09/IMG_3084.CR2
-rw-rw-r-- 1 david david 12564061 Aug 9 13:00 2012/08/09/IMG_3084.CR2
Lo stesso articolo mostrava una soluzione alternativa:
$ rsync -avhP --size-only --bwlimit=64 2012/08 /mnt/box/bwca/
Questo è un modo OK di usare rsync
, ma sta solo confrontando i file in base alle loro dimensioni ora, non ai loro checksum.
3. Problemi con davfs2 (WebDAV)
Mi sono imbattuto in questa discussione intitolata: rsync via davfs2? nel forum WebDAV (davfs) su sourceforge. Qualcuno si stava informando su una situazione simile in cui volevano utilizzare WebDAV per montare un provider di archiviazione online ed eseguire rsync sullo storage montato tramite WebDAV. Questo è ciò che uno degli sviluppatori (Werner Baumann) di WebDAV ha detto su questo argomento .
estratto della risposta di Werner
davfs2 caricherà solo file completi. Non può fare le cose incrementali che rsync di solito fa, e ciò rende rsync molto efficiente.
davfs2 utilizza una cache locale su disco. Ciò lo renderà più reattivo e anche la tua applicazione dovrebbe trarne vantaggio. Ma ha bisogno di spazio su disco locale per questo. Dovresti consentire una cache di grandi dimensioni, in modo che rsync possa fare la maggior parte del suo lavoro con la cache locale e davfs2 caricherà la maggior parte dei file in background, quando rsync avrà già terminato.
Werner continua a suggerire quanto segue
Questo potrebbe essere uno svantaggio in questo caso. Quando rsync legge un file sull'host remoto, deve prima essere trasferito da davfs2 nella cache locale (se non è già presente). Ciò potrebbe rallentare il processo davvero e inutilmente. Dato che rsync funziona solo come un sofisticato programma di copia nel tuo caso, potrebbe essere preferibile usare cp. cp ha un'opzione (-u) per copiare solo i file più recenti di quelli nel file system davfs2 (= smartdrive) e non avrebbe bisogno di leggere i file, ma legge solo i metadati dei file come mtime.
Un comando come "cp -pru directory / to / backup dav /" potrebbe fare il lavoro. Non deve scaricare file (come potrebbe fare rsync, ma non ne sono sicuro) (si prega di consultare i manuali di cp e rsync).
Opzioni?
Come ha suggerito @Anthon, è possibile utilizzare il cp -u
metodo per copiare i file. Rendersi conto che questo metodo considera solo le dimensioni di un file come un fattore di confronto, quindi non è completamente affidabile.
Non si deve usare tutto ciò che solo sembra a volte di modifica quando si confrontano i file, cp -pru
. Werner spiega perché in questa discussione :
estratto in questione con tempi mod
Quando si smonta un file system davfs2 e lo si monta nuovamente in un secondo momento, i tempi dei file potrebbero essere cambiati in base alle informazioni sul tempo dal server. Strumenti come cp -pu e rsync non possono fare affidamento su questi tempi per determinare quali file sono stati modificati.
Quindi, date le varie questioni relative ai tempi di modifica, un approccio che utilizza solo checksum sembra adattarsi meglio:
$ rsync -avvz --omit-dir-times --checksum --human-readable --progress <local dir> <remote dir>
--max-size=250M --exclude '.*'
. Sono sicuro checp
può essere fatto per fare questo ... forse convogliando l'output di find in cp? Ma non so ancora come farlo. Se troveremo una soluzione, proveròcp -ru
. Grazie