MyFavMirrors/minio
1
0
Fork 0
mirror of https://github.com/minio/minio.git synced 2024-12-26 07:05:55 -05:00
Code Issues Packages Projects Releases Wiki Activity
ae936a0147
minio/vendor/vendor.json

149 lines
4.4 KiB
JSON
Raw Normal View History

Migrate to govendor to avoid limitations of godep - over the course of a project history every maintainer needs to update its dependency packages, the problem essentially with godep is manipulating GOPATH - this manipulation leads to static objects created at different locations which end up conflicting with the overall functionality of golang. This also leads to broken builds. There is no easier way out of this other than asking developers to do 'godep restore' all the time. Which perhaps as a practice doesn't sound like a clean solution. On the other hand 'godep restore' has its own set of problems. - govendor is a right tool but a stop gap tool until we wait for golangs official 1.5 version which fixes this vendoring issue once and for all. - govendor provides consistency in terms of how import paths should be handled unlike manipulation GOPATH. This has advantages - no more compiled objects being referenced in GOPATH and build time GOPATH manging which leads to conflicts. - proper import paths referencing the exact package a project is dependent on. govendor is simple and provides the minimal necessary tooling to achieve this. For now this is the right solution.
2015-08-12 22:24:31 -04:00
{
"comment": "",
web: Removing dependency for gpg and downloading assets. Assets are vendorized from now on and updated for each release.
2016-02-23 16:05:47 -05:00
"ignore": "appengine test",
Migrate to govendor to avoid limitations of godep - over the course of a project history every maintainer needs to update its dependency packages, the problem essentially with godep is manipulating GOPATH - this manipulation leads to static objects created at different locations which end up conflicting with the overall functionality of golang. This also leads to broken builds. There is no easier way out of this other than asking developers to do 'godep restore' all the time. Which perhaps as a practice doesn't sound like a clean solution. On the other hand 'godep restore' has its own set of problems. - govendor is a right tool but a stop gap tool until we wait for golangs official 1.5 version which fixes this vendoring issue once and for all. - govendor provides consistency in terms of how import paths should be handled unlike manipulation GOPATH. This has advantages - no more compiled objects being referenced in GOPATH and build time GOPATH manging which leads to conflicts. - proper import paths referencing the exact package a project is dependent on. govendor is simple and provides the minimal necessary tooling to achieve this. For now this is the right solution.
2015-08-12 22:24:31 -04:00
"package": [
logrus logger
2015-09-09 23:28:09 -04:00
{
Migrate to new govendor
2015-10-11 01:28:56 -04:00
"path": "github.com/Sirupsen/logrus",
logrus logger
2015-09-09 23:28:09 -04:00
"revision": "418b41d23a1bf978c06faea5313ba194650ac088",
"revisionTime": "2015-09-08T20:46:18Z"
},
server: terminal width should fallback to 80x25. (#1895) Some environments might disable access to `/dev/tty`, fall back to '80' in such scenarios. Move to 'cheggaaa/pb' package for better cross platform support on fetching terminal width. Fixes #1891
2016-06-12 22:35:28 -04:00
{
"path": "github.com/cheggaaa/pb",
"revision": "c1f48d5ce4f292dfb775ef52aaedd15be323510d",
"revisionTime": "2016-05-20T13:10:51+03:00"
},
jwt: Add JWT support for minio server. Please read JWT.md before using this feature.
2016-01-21 19:28:15 -05:00
{
"path": "github.com/dgrijalva/jwt-go",
"revision": "afef698c326bfd906b11659432544e5aae441d44",
"revisionTime": "2015-12-30T10:00:00-08:00"
},
Migrate to govendor to avoid limitations of godep - over the course of a project history every maintainer needs to update its dependency packages, the problem essentially with godep is manipulating GOPATH - this manipulation leads to static objects created at different locations which end up conflicting with the overall functionality of golang. This also leads to broken builds. There is no easier way out of this other than asking developers to do 'godep restore' all the time. Which perhaps as a practice doesn't sound like a clean solution. On the other hand 'godep restore' has its own set of problems. - govendor is a right tool but a stop gap tool until we wait for golangs official 1.5 version which fixes this vendoring issue once and for all. - govendor provides consistency in terms of how import paths should be handled unlike manipulation GOPATH. This has advantages - no more compiled objects being referenced in GOPATH and build time GOPATH manging which leads to conflicts. - proper import paths referencing the exact package a project is dependent on. govendor is simple and provides the minimal necessary tooling to achieve this. For now this is the right solution.
2015-08-12 22:24:31 -04:00
{
Migrate to new govendor
2015-10-11 01:28:56 -04:00
"path": "github.com/dustin/go-humanize",
Migrate this project to minio micro services code
2015-10-16 14:26:01 -04:00
"revision": "c20a8bde38c8f5ba06f6600edf473705c96829d1",
"revisionTime": "2015-08-24T01:38:10-07:00"
Migrate to govendor to avoid limitations of godep - over the course of a project history every maintainer needs to update its dependency packages, the problem essentially with godep is manipulating GOPATH - this manipulation leads to static objects created at different locations which end up conflicting with the overall functionality of golang. This also leads to broken builds. There is no easier way out of this other than asking developers to do 'godep restore' all the time. Which perhaps as a practice doesn't sound like a clean solution. On the other hand 'godep restore' has its own set of problems. - govendor is a right tool but a stop gap tool until we wait for golangs official 1.5 version which fixes this vendoring issue once and for all. - govendor provides consistency in terms of how import paths should be handled unlike manipulation GOPATH. This has advantages - no more compiled objects being referenced in GOPATH and build time GOPATH manging which leads to conflicts. - proper import paths referencing the exact package a project is dependent on. govendor is simple and provides the minimal necessary tooling to achieve this. For now this is the right solution.
2015-08-12 22:24:31 -04:00
},
UI: vendorize github.com/elazarl/go-bindata-assetfs which is needed by ui-assets.go
2016-02-04 06:20:34 -05:00
{
"path": "github.com/elazarl/go-bindata-assetfs",
ui-assets: Integrate UI assets.
2016-02-04 19:00:52 -05:00
"revision": "57eb5e1fc594ad4b0b1dbea7b286d299e0cb43c2",
"revisionTime": "2015-12-24T06:54:52+02:00"
UI: vendorize github.com/elazarl/go-bindata-assetfs which is needed by ui-assets.go
2016-02-04 06:20:34 -05:00
},
Add WebUI assetfs initial version
2015-09-25 03:37:28 -04:00
{
Migrate this project to minio micro services code
2015-10-16 14:26:01 -04:00
"path": "github.com/fatih/color",
vendor: Update to new upstream changes from fatih/color Brings in changes like support for Solaris/FreeBSD.
2016-02-23 17:56:47 -05:00
"revision": "7a5857db0b2752a436d8461d88c42dea0ee191c0",
"revisionTime": "2016-02-12T11:24:09+02:00"
Migrate to govendor to avoid limitations of godep - over the course of a project history every maintainer needs to update its dependency packages, the problem essentially with godep is manipulating GOPATH - this manipulation leads to static objects created at different locations which end up conflicting with the overall functionality of golang. This also leads to broken builds. There is no easier way out of this other than asking developers to do 'godep restore' all the time. Which perhaps as a practice doesn't sound like a clean solution. On the other hand 'godep restore' has its own set of problems. - govendor is a right tool but a stop gap tool until we wait for golangs official 1.5 version which fixes this vendoring issue once and for all. - govendor provides consistency in terms of how import paths should be handled unlike manipulation GOPATH. This has advantages - no more compiled objects being referenced in GOPATH and build time GOPATH manging which leads to conflicts. - proper import paths referencing the exact package a project is dependent on. govendor is simple and provides the minimal necessary tooling to achieve this. For now this is the right solution.
2015-08-12 22:24:31 -04:00
},
{
Migrate this project to minio micro services code
2015-10-16 14:26:01 -04:00
"path": "github.com/gorilla/context",
"revision": "1c83b3eabd45b6d76072b66b746c20815fb2872d",
"revisionTime": "2015-08-19T22:12:45-07:00"
Migrate to govendor to avoid limitations of godep - over the course of a project history every maintainer needs to update its dependency packages, the problem essentially with godep is manipulating GOPATH - this manipulation leads to static objects created at different locations which end up conflicting with the overall functionality of golang. This also leads to broken builds. There is no easier way out of this other than asking developers to do 'godep restore' all the time. Which perhaps as a practice doesn't sound like a clean solution. On the other hand 'godep restore' has its own set of problems. - govendor is a right tool but a stop gap tool until we wait for golangs official 1.5 version which fixes this vendoring issue once and for all. - govendor provides consistency in terms of how import paths should be handled unlike manipulation GOPATH. This has advantages - no more compiled objects being referenced in GOPATH and build time GOPATH manging which leads to conflicts. - proper import paths referencing the exact package a project is dependent on. govendor is simple and provides the minimal necessary tooling to achieve this. For now this is the right solution.
2015-08-12 22:24:31 -04:00
},
browser-assets: serve asset files with compression.
2016-03-03 21:15:56 -05:00
{
"path": "github.com/gorilla/handlers",
"revision": "ee54c7b44cab12289237fb8631314790076e728b",
"revisionTime": "2016-02-28T09:16:04-08:00"
},
Migrate to govendor to avoid limitations of godep - over the course of a project history every maintainer needs to update its dependency packages, the problem essentially with godep is manipulating GOPATH - this manipulation leads to static objects created at different locations which end up conflicting with the overall functionality of golang. This also leads to broken builds. There is no easier way out of this other than asking developers to do 'godep restore' all the time. Which perhaps as a practice doesn't sound like a clean solution. On the other hand 'godep restore' has its own set of problems. - govendor is a right tool but a stop gap tool until we wait for golangs official 1.5 version which fixes this vendoring issue once and for all. - govendor provides consistency in terms of how import paths should be handled unlike manipulation GOPATH. This has advantages - no more compiled objects being referenced in GOPATH and build time GOPATH manging which leads to conflicts. - proper import paths referencing the exact package a project is dependent on. govendor is simple and provides the minimal necessary tooling to achieve this. For now this is the right solution.
2015-08-12 22:24:31 -04:00
{
Migrate this project to minio micro services code
2015-10-16 14:26:01 -04:00
"path": "github.com/gorilla/mux",
"revision": "ee1815431e497d3850809578c93ab6705f1a19f7",
"revisionTime": "2015-08-19T22:15:06-07:00"
Migrate to govendor to avoid limitations of godep - over the course of a project history every maintainer needs to update its dependency packages, the problem essentially with godep is manipulating GOPATH - this manipulation leads to static objects created at different locations which end up conflicting with the overall functionality of golang. This also leads to broken builds. There is no easier way out of this other than asking developers to do 'godep restore' all the time. Which perhaps as a practice doesn't sound like a clean solution. On the other hand 'godep restore' has its own set of problems. - govendor is a right tool but a stop gap tool until we wait for golangs official 1.5 version which fixes this vendoring issue once and for all. - govendor provides consistency in terms of how import paths should be handled unlike manipulation GOPATH. This has advantages - no more compiled objects being referenced in GOPATH and build time GOPATH manging which leads to conflicts. - proper import paths referencing the exact package a project is dependent on. govendor is simple and provides the minimal necessary tooling to achieve this. For now this is the right solution.
2015-08-12 22:24:31 -04:00
},
Bring in the list APIs implemented by Bala <bala@minio.io>
2016-01-23 22:44:32 -05:00
{
"path": "github.com/gorilla/rpc/v2",
"revision": "64e20900b8aa38bb0771dec71ba3bcc2b07fc8ec",
"revisionTime": "2015-11-05T07:45:51+08:00"
},
{
WebUI: move from rpc/v2/json to rpc/v2/json2 which has better error response structure.
2016-02-11 13:11:43 -05:00
"path": "github.com/gorilla/rpc/v2/json2",
rpc: Fix json rpc to handle array and object request params. rpc/v2/json2 code has a bug where it treats all jsonrpc 2.0 request params like an 'object'. In accordance with the spec it could be both 'object' or an 'array'. Handle both cases.
2016-02-13 21:50:21 -05:00
"revision": "64e20900b8aa38bb0771dec71ba3bcc2b07fc8ec",
"revisionTime": "2015-11-05T07:45:51+08:00"
Bring in the list APIs implemented by Bala <bala@minio.io>
2016-01-23 22:44:32 -05:00
},
rewrite minio runtime checks
2016-02-15 07:26:56 -05:00
{
"path": "github.com/hashicorp/go-version",
"revision": "7e3c02b30806fa5779d3bdfc152ce4c6f40e7b38",
"revisionTime": "2016-01-19T13:13:26-08:00"
},
cpu: Remove pkg/cpu in favor of better klauspost/cpuid. Fixes #1128
2016-02-15 15:45:02 -05:00
{
"path": "github.com/klauspost/cpuid",
"revision": "349c675778172472f5e8f3a3e0fe187e302e5a10",
"revisionTime": "2016-01-06T11:44:51+01:00"
},
Implement XL layer - preliminary work.
2016-03-28 00:52:38 -04:00
{
"path": "github.com/klauspost/reedsolomon",
vendor: update klauspost/reedsomon package with upstream changes. (#1912)
2016-06-17 05:46:26 -04:00
"revision": "2fde63d2889a399426862a16611c489b1fed87bc",
"revisionTime": "2016-06-04T08:05:20+02:00"
Implement XL layer - preliminary work.
2016-03-28 00:52:38 -04:00
},
vendor: Update to new upstream changes from fatih/color Brings in changes like support for Solaris/FreeBSD.
2016-02-23 17:56:47 -05:00
{
"path": "github.com/mattn/go-colorable",
"revision": "9cbef7c35391cca05f15f8181dc0b18bc9736dbb",
"revisionTime": "2016-02-20T16:59:35+09:00"
},
First time mode for controller - Upon first time invocation ``minio controller`` would create access keys and secret id - Upon request passing 'keys' arg ``minio controller`` would provide the keys - Add colorized notification
2015-10-04 19:31:07 -04:00
{
Migrate this project to minio micro services code
2015-10-16 14:26:01 -04:00
"path": "github.com/mattn/go-isatty",
"revision": "7fcbc72f853b92b5720db4a6b8482be612daef24",
"revisionTime": "2015-08-14T09:26:29+09:00"
First time mode for controller - Upon first time invocation ``minio controller`` would create access keys and secret id - Upon request passing 'keys' arg ``minio controller`` would provide the keys - Add colorized notification
2015-10-04 19:31:07 -04:00
},
XL/bitrot: Migrate to new blake2b-simd SIMD optimized implementation. (#2031) Thanks for Frank Wessels <fwessels@xs4all.nl> for all the heavy lifting work. Comparative benchmarks are as below. ``` benchmark old ns/op new ns/op delta BenchmarkHash64-4 742 411 -44.61% BenchmarkHash128-4 681 346 -49.19% BenchmarkWrite1K-4 4239 1497 -64.69% BenchmarkWrite8K-4 33633 11514 -65.77% BenchmarkWrite32K-4 134091 45947 -65.73% BenchmarkWrite128K-4 537976 183643 -65.86% benchmark old MB/s new MB/s speedup BenchmarkHash64-4 86.18 155.51 1.80x BenchmarkHash128-4 187.96 369.10 1.96x BenchmarkWrite1K-4 241.55 683.87 2.83x BenchmarkWrite8K-4 3897.06 11383.41 2.92x BenchmarkWrite32K-4 977.48 2852.63 2.92x BenchmarkWrite128K-4 243.64 713.73 2.93x ``` Fixes #2030
2016-06-29 05:06:35 -04:00
{
"path": "github.com/minio/blake2b-simd",
"revision": "0b3e695ecc77a334fafe30ee36de504c41ec4d6a",
"revisionTime": "2016-06-28T02:55:56-07:00"
},
Migrate to govendor to avoid limitations of godep - over the course of a project history every maintainer needs to update its dependency packages, the problem essentially with godep is manipulating GOPATH - this manipulation leads to static objects created at different locations which end up conflicting with the overall functionality of golang. This also leads to broken builds. There is no easier way out of this other than asking developers to do 'godep restore' all the time. Which perhaps as a practice doesn't sound like a clean solution. On the other hand 'godep restore' has its own set of problems. - govendor is a right tool but a stop gap tool until we wait for golangs official 1.5 version which fixes this vendoring issue once and for all. - govendor provides consistency in terms of how import paths should be handled unlike manipulation GOPATH. This has advantages - no more compiled objects being referenced in GOPATH and build time GOPATH manging which leads to conflicts. - proper import paths referencing the exact package a project is dependent on. govendor is simple and provides the minimal necessary tooling to achieve this. For now this is the right solution.
2015-08-12 22:24:31 -04:00
{
Migrate this project to minio micro services code
2015-10-16 14:26:01 -04:00
"path": "github.com/minio/cli",
cli: vendorize to new CLI package updates. - Fix a new line issue for minioHelpTemplate. - Fixes #974
2015-11-21 11:57:38 -05:00
"revision": "c4a07c7b68db77ccd119183fb1d01dd5972434ab",
"revisionTime": "2015-11-18T20:00:48-08:00"
Migrate to govendor to avoid limitations of godep - over the course of a project history every maintainer needs to update its dependency packages, the problem essentially with godep is manipulating GOPATH - this manipulation leads to static objects created at different locations which end up conflicting with the overall functionality of golang. This also leads to broken builds. There is no easier way out of this other than asking developers to do 'godep restore' all the time. Which perhaps as a practice doesn't sound like a clean solution. On the other hand 'godep restore' has its own set of problems. - govendor is a right tool but a stop gap tool until we wait for golangs official 1.5 version which fixes this vendoring issue once and for all. - govendor provides consistency in terms of how import paths should be handled unlike manipulation GOPATH. This has advantages - no more compiled objects being referenced in GOPATH and build time GOPATH manging which leads to conflicts. - proper import paths referencing the exact package a project is dependent on. govendor is simple and provides the minimal necessary tooling to achieve this. For now this is the right solution.
2015-08-12 22:24:31 -04:00
},
rewrite minio runtime checks
2016-02-15 07:26:56 -05:00
{
"path": "github.com/minio/go-homedir",
vendor update for go-homedir
2016-02-18 02:32:41 -05:00
"revision": "0b1069c753c94b3633cc06a1995252dbcc27c7a6",
"revisionTime": "2016-02-15T17:25:11+05:30"
rewrite minio runtime checks
2016-02-15 07:26:56 -05:00
},
console: Fix console color printing on windows. Print colored accessKeyID and secretAccessKey are unreadable on windows on command prompts and powershell. Use the console package from minio client.
2016-03-04 04:50:59 -05:00
{
"path": "github.com/minio/mc/pkg/console",
"revision": "db6b4f13442b26995f04b3b2b31b006cae7786e6",
"revisionTime": "2016-02-29T08:42:30-08:00"
},
web: Removing dependency for gpg and downloading assets. Assets are vendorized from now on and updated for each release.
2016-02-23 16:05:47 -05:00
{
"path": "github.com/minio/miniobrowser",
Web: Update with ui changes. (#1808)
2016-05-31 05:01:02 -04:00
"revision": "9c9fbc91e4b2e952048f9299c45d53ee0a0d0f2b",
"revisionTime": "2016-05-30T17:30:33-07:00"
web: Removing dependency for gpg and downloading assets. Assets are vendorized from now on and updated for each release.
2016-02-23 16:05:47 -05:00
},
rewrite minio runtime checks
2016-02-15 07:26:56 -05:00
{
"path": "github.com/mitchellh/go-homedir",
"revision": "d682a8f0cf139663a984ff12528da460ca963de9",
"revisionTime": "2015-10-24T22:24:27-07:00"
},
server: Enable server profiling as needed. (#1565)
2016-05-09 19:18:56 -04:00
{
"path": "github.com/pkg/profile",
vendor changes to pkg/profile (#1671)
2016-05-18 12:22:06 -04:00
"revision": "c78aac22bd43883fd2817833b982153dcac17b3b",
"revisionTime": "2016-05-18T16:56:57+10:00"
server: Enable server profiling as needed. (#1565)
2016-05-09 19:18:56 -04:00
},
Enable controller to have CORS
2015-08-31 04:47:05 -04:00
{
Migrate to new govendor
2015-10-11 01:28:56 -04:00
"path": "github.com/rs/cors",
Enable controller to have CORS
2015-08-31 04:47:05 -04:00
"revision": "eb527c8097e0f19a3ff7b253a3fe70545070f420",
"revisionTime": "2015-08-29T22:34:20-07:00"
},
backend/fs: Refactor multipart upload This patch modifies multipart upload related functions as below * New multipart upload call creates file EXPORT_DIR/.minio/BUCKET/PATH/TO/OBJECT/UPLOAD_ID.uploadid * Put object part call creates file EXPORT_DIR/.minio/BUCKET/PATH/TO/OBJECT/UPLOAD_ID.PART_NUMBER.MD5SUM_STRING * Abort multipart call removes all files matching EXPORT_DIR/.minio/BUCKET/PATH/TO/OBJECT/UPLOAD_ID.* * Complete multipart call does 1. creates a staging file EXPORT_DIR/.minio/BUCKET/PATH/TO/OBJECT/UPLOAD_ID.complete.TEMP_NAME then renames to EXPORT_DIR/.minio/BUCKET/PATH/TO/OBJECT/UPLOAD_ID.complete 2. rename staging file EXPORT_DIR/.minio/BUCKET/PATH/TO/OBJECT/UPLOAD_ID.complete to EXPORT_DIR/BUCKET/PATH/TO/OBJECT
2016-03-28 12:52:09 -04:00
{
"checksumSHA1": "u0hXGADM3JDza8YjgiyNJpAJk8g=",
"path": "github.com/skyrings/skyring-common/tools/uuid",
"revision": "762fd2bfc12e766d90478d638255981ab1966a3d",
"revisionTime": "2016-03-24T19:44:43+05:30"
},
jwt: Add JWT support for minio server. Please read JWT.md before using this feature.
2016-01-21 19:28:15 -05:00
{
"path": "golang.org/x/crypto/bcrypt",
"revision": "7b85b097bf7527677d54d3220065e966a0e3b613",
"revisionTime": "2015-11-30T17:07:01-05:00"
},
{
"path": "golang.org/x/crypto/blowfish",
"revision": "7b85b097bf7527677d54d3220065e966a0e3b613",
"revisionTime": "2015-11-30T17:07:01-05:00"
},
Migrate to govendor to avoid limitations of godep - over the course of a project history every maintainer needs to update its dependency packages, the problem essentially with godep is manipulating GOPATH - this manipulation leads to static objects created at different locations which end up conflicting with the overall functionality of golang. This also leads to broken builds. There is no easier way out of this other than asking developers to do 'godep restore' all the time. Which perhaps as a practice doesn't sound like a clean solution. On the other hand 'godep restore' has its own set of problems. - govendor is a right tool but a stop gap tool until we wait for golangs official 1.5 version which fixes this vendoring issue once and for all. - govendor provides consistency in terms of how import paths should be handled unlike manipulation GOPATH. This has advantages - no more compiled objects being referenced in GOPATH and build time GOPATH manging which leads to conflicts. - proper import paths referencing the exact package a project is dependent on. govendor is simple and provides the minimal necessary tooling to achieve this. For now this is the right solution.
2015-08-12 22:24:31 -04:00
{
Migrate to new govendor
2015-10-11 01:28:56 -04:00
"path": "gopkg.in/check.v1",
Migrate to govendor to avoid limitations of godep - over the course of a project history every maintainer needs to update its dependency packages, the problem essentially with godep is manipulating GOPATH - this manipulation leads to static objects created at different locations which end up conflicting with the overall functionality of golang. This also leads to broken builds. There is no easier way out of this other than asking developers to do 'godep restore' all the time. Which perhaps as a practice doesn't sound like a clean solution. On the other hand 'godep restore' has its own set of problems. - govendor is a right tool but a stop gap tool until we wait for golangs official 1.5 version which fixes this vendoring issue once and for all. - govendor provides consistency in terms of how import paths should be handled unlike manipulation GOPATH. This has advantages - no more compiled objects being referenced in GOPATH and build time GOPATH manging which leads to conflicts. - proper import paths referencing the exact package a project is dependent on. govendor is simple and provides the minimal necessary tooling to achieve this. For now this is the right solution.
2015-08-12 22:24:31 -04:00
"revision": "11d3bc7aa68e238947792f30573146a3231fc0f1",
"revisionTime": "2015-07-29T10:04:31+02:00"
}
backend/fs: Refactor multipart upload This patch modifies multipart upload related functions as below * New multipart upload call creates file EXPORT_DIR/.minio/BUCKET/PATH/TO/OBJECT/UPLOAD_ID.uploadid * Put object part call creates file EXPORT_DIR/.minio/BUCKET/PATH/TO/OBJECT/UPLOAD_ID.PART_NUMBER.MD5SUM_STRING * Abort multipart call removes all files matching EXPORT_DIR/.minio/BUCKET/PATH/TO/OBJECT/UPLOAD_ID.* * Complete multipart call does 1. creates a staging file EXPORT_DIR/.minio/BUCKET/PATH/TO/OBJECT/UPLOAD_ID.complete.TEMP_NAME then renames to EXPORT_DIR/.minio/BUCKET/PATH/TO/OBJECT/UPLOAD_ID.complete 2. rename staging file EXPORT_DIR/.minio/BUCKET/PATH/TO/OBJECT/UPLOAD_ID.complete to EXPORT_DIR/BUCKET/PATH/TO/OBJECT
2016-03-28 12:52:09 -04:00
],
"rootPath": "github.com/minio/minio"
Migrate to new govendor
2015-10-11 01:28:56 -04:00
}
Reference in New Issue Copy Permalink