mc mirror --overwrite deve detectar arquivos alterados
Parece, atualmente não
$ 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
versão mc RELEASE.2020-01-25T03-02-19Z
Cliente e servidor: Fedora 31 com XFS como sistema de arquivos
versão minio 2020-01-25T02: 50: 51Z
Com --overwrite e --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 isso é realmente conhecido e esperado. O espelho mc não detecta mudanças em um arquivo se seu tamanho não mudar, como one
& two
tem o mesmo comprimento.
@vadmeste Qual é a limitação que causa isso? Parece inconveniente na melhor das hipóteses.
@vadmeste Qual é a limitação que causa isso? Parece inconveniente na melhor das hipóteses.
Nenhuma soma de verificação armazenada no lado do servidor (ETag não é igual à soma md5 do objeto em alguns casos)
No canal Slack, alguns confirmaram que deveria funcionar ao usar --preserve
@vadmeste Qual é a limitação que causa isso? Parece inconveniente na melhor das hipóteses.
Nenhuma soma de verificação armazenada no lado do servidor (ETag não é igual à soma md5 do objeto em alguns casos)
Ai. Isso significa que, para fazer um instantâneo de certas coisas, precisaríamos contar com o rsync.
Existe uma maneira de acrescentar / alterar alguns metadados inofensivos que são verificados para forçar isso? Ou garantir que etag seja igual a hash?
Nenhuma soma de verificação armazenada no lado do servidor (ETag não é igual à soma md5 do objeto em alguns casos)
Ai. Isso significa que, para fazer um instantâneo de certas coisas, precisaríamos contar com o rsync.
Existe uma maneira de acrescentar / alterar alguns metadados inofensivos que são verificados para forçar isso? Ou garantir que etag seja igual a hash?
Para isso, use rclone
@seqizz que calcula a soma de verificação de todo o conteúdo - ETag não é md5sum nem sempre vê SSE-C, Multipart etc - e md5sum não é confiável, muitos objetos podem simplesmente corresponder ao mesmo md5sum - https: //www.mscs.dal.ca/~selinger/md5collision/ e é bastante comum, aparentemente em grande escala.
A menos, é claro, que possamos calcular a soma de verificação de objetos inteiros usando técnicas como blake2b - precisamos calcular isso antes de enviar o conteúdo, tornando mais lento o que você vai enviar.
O rsync destina-se a disco local para disco remoto usando protocolo delta que lê ambas as extremidades para a soma de verificação, o que seria inesperado no caso de armazenamento de objetos, devido aos custos de nuvem.
Ah, é claro, estou apenas atirando gratuitamente, já que não estou vinculado aos "custos de tráfego da nuvem" :) Vou verificar o rclone. Obrigado.
Por curiosidade, seria possível adicionar outro cabeçalho como etag, mas contendo hash para minio (na criação / modificação), sem quebrar a compatibilidade?
Por curiosidade, seria possível adicionar outro cabeçalho como etag, mas contendo hash para minio (na criação / modificação), sem quebrar a compatibilidade?
É definitivamente possível que @seqizz seja muito específico para mc
, o que significa que não temos controle sobre seu back-end de armazenamento de qualquer maneira, então qualquer mudança de estado não seria devidamente entendida por mc
.
isso pode levar a problemas de cópia dupla, etc., que são deixados de lado propositalmente, pois não conseguimos descobrir uma maneira econômica de fazê-lo adequadamente para todos os casos de uso generalizados.
Esse problema pode ser resolvido, então?
IMHO isso precisa ser documentado de forma mais clara, de preferência na seção espelho da documentação do MC diretamente.
Mas sim, se é assim que o minio funciona, não parece um bug. 👍
Este problema foi marcado automaticamente como obsoleto porque não teve atividades recentes. Estará fechado após 21 dias se não houver mais atividades. Obrigado por suas contribuições.
Comentários muito úteis
Com --overwrite e --preserve: