mc mirror --overwrite devrait détecter les fichiers modifiés
Il semble que ce ne soit pas le cas actuellement
$ mc mb myminio/mybucket
Bucket created successfully `myminio/mybucket`.
$ echo one > testdir/testfile.txt
$ cat testdir/testfile.txt
one
$ mc mirror --overwrite testdir myminio/mybucket
...estfile.txt: 4 B / 4 B ┃▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓┃ 227 B/s 0s
$ mc cat myminio/mybucket/testfile.txt
one
$ echo two > testdir/testfile.txt
$ cat testdir/testfile.txt
two
$ mc mirror --overwrite testdir myminio/mybucket
0 B / ? ┃░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░▓┃ 0s
$ mc cat myminio/mybucket/testfile.txt
one
version mc LIBÉRATION.2020-01-25T03-02-19Z
Client et serveur : Fedora 31 avec XFS comme système de fichiers
version minio 2020-01-25T02:50:51Z
Avec --overwrite et --preserve :
$ mc mb myminio/mybucket
Bucket created successfully `myminio/mybucket`.
$ echo one > testdir/testfile.txt
$ cat testdir/testfile.txt
one
$ mc mirror --overwrite --preserve testdir myminio/mybucket
...estfile.txt: 4 B / 4 B ┃▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓┃ 283 B/s 0s
$ mc cat myminio/mybucket/testfile.txt
one
$ echo two > testdir/testfile.txt
$ cat testdir/testfile.txt
two
$ mc mirror --overwrite --preserve testdir myminio/mybucket
0 B / ? ┃░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░▓┃ 0s
$ mc cat myminio/mybucket/testfile.txt
one
@sebschlue c'est en fait connu et attendu. mc mirror ne détecte pas les changements dans un fichier si sa taille ne change pas, comme one
& two
a la même longueur.
@vadmeste Quelle est la limitation qui provoque cela ? Cela semble au mieux incommode.
@vadmeste Quelle est la limitation qui provoque cela ? Cela semble au mieux incommode.
Aucune somme de contrôle stockée côté serveur (ETag n'est pas égal à la somme md5 de l'objet dans certains cas)
Sur le canal Slack, certains ont confirmé que cela devrait fonctionner lors de l'utilisation de --preserve
@vadmeste Quelle est la limitation qui provoque cela ? Cela semble au mieux incommode.
Aucune somme de contrôle stockée côté serveur (ETag n'est pas égal à la somme md5 de l'objet dans certains cas)
Aie. Cela signifie que pour prendre des instantanés de certaines choses, nous devons nous fier à rsync.
Existe-t-il un moyen d'ajouter / de modifier des métadonnées inoffensives qui sont vérifiées pour forcer cela ? Ou s'assurer que etag est égal au hachage ?
Aucune somme de contrôle stockée côté serveur (ETag n'est pas égal à la somme md5 de l'objet dans certains cas)
Aie. Cela signifie que pour prendre des instantanés de certaines choses, nous devons nous fier à rsync.
Existe-t-il un moyen d'ajouter / de modifier des métadonnées inoffensives qui sont vérifiées pour forcer cela ? Ou s'assurer que etag est égal au hachage ?
Pour cela, utilisez rclone
@seqizz qui calcule la somme de contrôle de tout le contenu - ETag n'est pas md5sum pas toujours voir SSE-C, Multipart etc - et md5sum n'est pas fiable, de nombreux objets peuvent simplement correspondre à la même somme md5 - https : //www.mscs.dal.ca/~selinger/md5collision/ et c'est assez courant apparemment à grande échelle.
À moins bien sûr que nous puissions calculer la somme de contrôle d'objets entiers à l'aide de techniques telles que blake2b - nous devons le calculer avant de télécharger le contenu, ce qui ralentit considérablement ce que vous allez télécharger.
rsync est destiné à un disque local vers un disque distant utilisant le protocole delta qui lit les deux extrémités pour la somme de contrôle, ce qui serait inattendu en cas de stockage d'objets, en raison des coûts du cloud.
Ah, bien sûr, je ne fais que du free-shooting car actuellement je ne suis pas lié par les "coûts du trafic cloud" :) Je vais vérifier le rclone. Merci.
Juste curieux, serait-il même possible d'ajouter un autre en-tête comme etag mais contenant du hachage pour minio (sur créer/modifier), sans casser la compatibilité ?
Juste curieux, serait-il même possible d'ajouter un autre en-tête comme etag mais contenant du hachage pour minio (sur créer/modifier), sans casser la compatibilité ?
Il est certainement possible que @seqizz soit très spécifique à mc
, ce qui signifie que nous n'avons de toute façon aucun contrôle sur votre backend de stockage, donc tout changement d'état là-bas ne serait pas correctement compris par mc
.
cela peut conduire à des problèmes de double copie, etc., cela est volontairement laissé de côté, car nous ne pouvions pas trouver un moyen rentable de le faire correctement pour tous les cas d'utilisation généralisés.
Ce problème peut-il être clos alors ?
À mon humble avis, cela doit être documenté plus clairement, de préférence dans la section miroir de la documentation mc directement.
Mais oui, si c'est ainsi que minio fonctionne, cela ne ressemble pas à un bug. ??
Ce problème a été automatiquement marqué comme obsolète car il n'a pas eu d'activité récente. Il sera fermé après 21 jours si aucune autre activité ne se produit. Merci pour vos contributions.
Commentaire le plus utile
Avec --overwrite et --preserve :