<p>mc funktioniert nicht mit GCS-Buckets, die Unterstriche im Namen enthalten</p>
Die Validierung, die mc für Bucket-Namen durchführt, beschränkt sie auf eine DNS-fähige Teilmenge von Zeichen. Google Cloud Storage scheint jedoch andere Zeichen zuzulassen. Dies führt dazu, dass mc bei einigen GCS-Buckets keine Vorgänge ausführen kann.
Gibt es eine Möglichkeit, diese Einschränkung pro Alias zu lockern? Mein Anwendungsfall hier ist, Daten zwischen GCS und S3 übertragen zu können, und das kann ich derzeit nicht für alle Buckets, mit denen ich arbeite. Siehe unten für den Fehler, den ich erhalte.
$ ./mc config host add gcs https://storage.googleapis.com GOOGXXXXXXXXXXXXXXXX eb4XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX S3v2
$ ./mc ls gcs
[2016-03-21 15:30:02 GMT] 0B dw_export/
$ ./mc ls gcs/dw_export/
mc: <ERROR> Unable to stat ‘gcs/dw_export/’. Bucket name contains invalid characters.
d5ve
Alle 6 Kommentare
$ ./mc config host gcs hinzufügen https://storage.googleapis.com GOOGXXXXXXXXXXXXXXXX eb4XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX S3v2
$ ./mc ls gcs
[2016-03-21 15:30:02 GMT] 0B dw_export/
$ ./mc ls gcs/dw_export/
mc:'gcs/dw_export/' kann nicht angegeben werden. Bucket-Name enthält ungültige Zeichen.
Derzeit sind Ja-Buckets basierend auf den Benennungsanforderungen für S3-Buckets eingeschränkt, dh folgen Sie den Bucket-Einschränkungen von hier http://docs.aws.amazon.com/AmazonS3/latest/dev/BucketRestrictions.html
Mal sehen, ob es eine Möglichkeit gibt, dies nur für GCs zu entspannen.
harshavardhana
am 5. Apr. 2016
Können wir Benennungs-/Validierungskonventionen für Buckets haben, die für jeden Speicheranbieter spezifisch sind? Es kann sehr praktisch sein, wenn wir mehrere Anbieter mit jeweils eigenen Einschränkungen unterstützen. Die Richtlinienänderungen des einen werden den anderen nicht brechen.
sreeram-boyapati
am 18. Apr. 2016
Können wir Benennungs-/Validierungskonventionen für Buckets haben, die für jeden Speicheranbieter spezifisch sind? Es kann sehr praktisch sein, wenn wir mehrere Anbieter mit jeweils eigenen Einschränkungen unterstützen. Die Richtlinienänderungen des einen werden den anderen nicht brechen.
Das Problem mit Google Cloud Storage besteht darin, dass es nicht vollständig S3-kompatibel ist. 'mc' ist ein Tool, das nur für 'S3'-kompatible Objektspeicher wie S3, Minio, Ceph oder Swift und Filesystems geschrieben wurde. - Aus diesem Grund ist es nicht sinnvoll, wörtliche Lösungen pro Anbieter hinzuzufügen, da es sich nicht um ein generisches Datentransfertool für alle Anbietertypen handelt.
Was getan werden kann, ist die Lockerung der Bucket-Einschränkungen speziell für 'GCS', dies erfordert Codeänderungen in minio-go.
harshavardhana
am 18. Apr. 2016
Damit Minio funktioniert, übertrage ich mein Backet mit Namen ohne Unterstrich.
Danach konnte ich diesen Eimer spiegeln.
skipp
am 18. Apr. 2016
Wir sollten Benutzer nur ermutigen, Best Practices zu befolgen. Wenn wir es lockern, wird die Datenmigration zwischen GCS, AWS und Minio schwieriger und die Benutzer werden immer auf mc angewiesen sein.
GarimaKapoor
am 19. Juli 2016
Dieser Thread wurde automatisch gesperrt, da nach dem Schließen in letzter Zeit keine Aktivität stattgefunden hat. Bitte öffnen Sie eine neue Ausgabe für verwandte Fehler.
![lock[bot] picture](https://avatars.githubusercontent.com/in/6672?v=4&s=40)
lock[bot]
am 26. Apr. 2020
Verwandte Themen
TJC
·
10Kommentare
roman-m-work
·
4Kommentare
silvernode
·
8Kommentare
donatello
·
5Kommentare
ramosisw
·
4Kommentare
Hilfreichster Kommentar
Derzeit sind Ja-Buckets basierend auf den Benennungsanforderungen für S3-Buckets eingeschränkt, dh folgen Sie den Bucket-Einschränkungen von hier http://docs.aws.amazon.com/AmazonS3/latest/dev/BucketRestrictions.html
Mal sehen, ob es eine Möglichkeit gibt, dies nur für GCs zu entspannen.