Assurez-vous que le téléchargement n'est pas une dupe


3

Je souhaite télécharger (de manière récursive) un répertoire de fichiers vers un emplacement à partir d'un serveur WebDav. Si le fichier est déjà présent (quelque part là-bas), il ne sera pas téléchargé à nouveau. Cependant, la structure des dossiers n'est pas la même.

Y a-t-il un moyen facile de faire ça? J'ai regardé dans fdupes, mais c'est juste pour la détection et la suppression des dupes. Les fichiers sont très volumineux et les frais généraux seraient de loin trop importants.

Le système de fichiers cible ne prend pas en charge la déduplication. Je sais cp -n(à partir d'un point de montage FUSE) ne pas écraser les fichiers existants, mais la structure des dossiers n'est pas la même. Donc je suis un peu coincé.

Réponses:


3

En regardant les clients Linux disponibles pour WebDAV , ma méthode préférée pour ce faire serait:

  1. Utilisez GVFS ou l'un des modules du système de fichiers WebDAV (davfs2 ou fusedav) pour "mapper" les fichiers du serveur WebDAV distant dans le chemin du système de fichiers local.

  2. Utilisez la commande cp intégrée avec l' -noption pour lui demander de ne pas "encombrer" les fichiers de la destination. Notez que certains shells, tels que dashsur Ubuntu, exécuteront une builtinversion de cppar défaut et que cette fonctionnalité intégrée pourrait ne pas prendre en charge l' -noption. Pour de meilleurs résultats, assurez-vous d’exécuter la version GNU Coreutils cpen exécutant /bin/cpou /usr/bin/cp(en fonction de l’emplacement du fichier binaire sur votre système spécifique).

EDIT: J'ai mal lu votre question initiale.

Je pense que ce que vous dites, c'est que vous vous trouvez dans la situation où le fichier file1.txtexiste dans deux chemins différents sur le serveur WebDAV et que le contenu de ces deux fichiers est exactement le même. Et puisque vous avez déjà une copie du fichier, vous ne souhaitez pas télécharger une deuxième ou une troisième copie du fichier car elle gaspille de la bande passante?

Eh bien, du côté client , ce serait très difficile à faire. Voici pourquoi.

Vous devez regarder ce que vous comparez pour déterminer si le fichier est unique, ainsi que les exigences / coûts pour effectuer cette comparaison.

J'ai supposé (à tort) que vous étiez en train de comparer le chemin relatif à la racine de la structure de dossiers WebDAV. Le coût de la comparaison d'égalité de chemin est très simple: il suffit de regarder les deux chaînes de chemin, comme /dir1/dir2/file1.txt, et de voir si les chaînes correspondent. S'ils le font, c'est un doublon. Si ce n'est pas le cas, ce n'est pas le cas.

Une autre chose que vous pouvez comparer est le nom du fichier , en ignorant le chemin . Ainsi, par exemple, considéreriez-vous ces deux fichiers en double: /dir1/dir2/file1.txtet /dir3/dir4/file1.txt? Eh bien, si vous comparez uniquement en fonction du nom , ceux-ci seront considérés comme des doublons. Cependant, nous pouvons mélanger et faire correspondre différents tests de duplication à notre guise, afin de réaliser le type de test adapté à notre cas d'utilisation.

D'autres propriétés moins utiles pour comparer comprennent la taille de fichier , les attributs (également appelés métadonnées ), l'extension de fichier, etc. Il est facile de construire un fichier qui a les mêmes propriétés qu’un autre fichier, mais un contenu totalement différent, et la plupart des gens ne considéreraient pas que les deux fichiers sont des doublons si le contenu diffère.

À mon avis, la chose la plus importante que vous puissiez comparer est le contenu du fichier . Malheureusement, du point de vue d'un client WebDAV, vous n'avez aucun moyen de connaître le contenu du fichier tant que vous n'avez pas déjà téléchargé le fichier. Et en ce qui concerne le client, le contenu du fichier peut changer pendant ou après le transfert de fichier. Dans ce cas, les résultats de la comparaison des doublons changeront si vous téléchargez à nouveau le fichier.

Il existe deux méthodes de base pour comparer le contenu du fichier: octet pour octet et hachage . Octet pour octet est le moyen le plus "garanti" de vérifier les doublons, mais il est contraint de comparer le fichier entier , ce qui est extrêmement lent pour une grande quantité de données. Considérez également que la détection des doublons présente une complexité algorithmique de base O(n^2), ce qui signifie que vous devez comparer le contenu de chaque fichier avec le contenu de chaque fichier afin de déterminer s'il s'agit d'un doublon. L'utilisation d'un hachage cryptographique pour comparer les fichiers peut considérablement réduire la quantité de données à comparer ou à transférer, mais l'inconvénient est que vous introduisez une chance infiniment petite que deux fichiers soient réellement différents. mais avoir le même hachage - connu comme une collision de hachage.

Mais encore une fois, du client point de vue, il est impossible de savoir ce que le contenu du fichier sont, ou même son hachage, à moins que vous soit:

  • Téléchargez le fichier depuis le serveur. ou
  • Convaincez le serveur de calculer une valeur de hachage pour vous localement, puis téléchargez-le.

Dans le premier cas, vous téléchargez le fichier pour déterminer s'il s'agit d'une copie afin d'éviter de le télécharger. Vous ne pouvez donc pas le faire. Évidemment, vous gaspillez la bande passante que vous essayez d'éviter pour effectuer les comparaisons. !

Dans ce dernier cas, vous pourriez être sur quelque chose. Un hachage SHA1 d'un très gros fichier ne représente que quelques octets et représente une infime fraction de la taille du gros fichier. Il serait assez pratique pour télécharger hash de tous les fichiers et faire une O(n^2)comparaison des hash pour déterminer le fichier à télécharger. Vous rencontrez toujours des problèmes de concurrence si les données du fichier changent sur le serveur pendant que vous effectuez ces comparaisons. Vous devez donc vous assurer de prendre en compte la synchronisation si elle est importante pour vous.

Donc, conclusion:

  • SI vous ne possédez pas un contrôle logiciel total sur le serveur WebDAV et que vous ne parvenez pas à modifier sa configuration, vous êtes quasiment à l'abri de la chance (tm) de déterminer si vous avez déjà une copie du même contenu de fichier qui est stocké dans plusieurs fichiers sur le serveur, sauf si l’administrateur du serveur met déjà à disposition une sorte de fichier de hachage pour chaque fichier sur le serveur, ce qui peut vous permettre un certain succès si vous pouvez vous fier aux valeurs de hachage.
  • SI vous faire le plein contrôle du logiciel sur le serveur WebDAV et sont en mesure de changer sa configuration, vous pouvez écrire un script ou un programme (ou utiliser un déjà disponible) pour créer un fichier de hachage avec une extension telle que, par exemple .sha1sumdans le même répertoire que tous les fichiers hébergés par le serveur WebDAV. Cela pourrait vous permettre de télécharger uniquement les hachages et de les comparer, à un coût de bande passante relativement modeste comparé à la taille des fichiers, en supposant que vos fichiers ont une taille supérieure à quelques kilo-octets.

Je veux dire que le fichier n'est présent dans aucun sous-dossier, ni nulle part ailleurs à cet endroit
wishi

1
OH. Vous voulez dire que le fichier existe dans le chemin /dir1/dir2/file1.txt AND /dir3/dir4/file1.txt et que les deux fichiers sont des copies l'un de l'autre? Ce serait un problème. : S
allquixotic

Merci pour cette réponse. L'approche avec hashsums et une liste est la voie à suivre. Avec du Python. Je ne savais pas s'il existait une astuce bien connue prête à l'emploi avec de la magie awk / sed / cp / md5sum :) Parfois, il y en avait. Et d'habitude je suis la dernière personne qui sait.
Wishi

1
Hé, si vous parvenez à développer quelque chose en Python qui soit généralement utile, vous devriez publier votre code sur github, etc. et éditer ma réponse (et / ou votre question) en fournissant ce que vous avez appris :) Cela serait extrêmement utile pour ceux qui avoir le même problème.
Allquixotic
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.