upyun / go-sdk Goto Github PK

执行go install github.com/upyun/go-sdk/upyun错误，出现

can't load package: package github.com/upyun/go-sdk/upyun

go: downloading github.com/upyun/go-sdk/v3 v3.0.0
go get github.com/upyun/go-sdk/v3/upyun: github.com/upyun/go-sdk/[email protected]: verifying module: checksum mismatch
downloaded: h1:Qx/6C961SOicM/+a7PJW8K+e/0WLnwTZ9qfKFD/RnGQ=
sum.golang.org: h1:AXmeuTWJp3oZUjXX/45RssJTndcxAbvGZqtsgKxuMIM=

SECURITY ERROR
This download does NOT match the one reported by the checksum server.
The bits may have been replaced on the origin server, or an attacker may
have intercepted the download attempt.

For more information, see 'go help module-auth'.

go: downloading github.com/upyun/go-sdk/v3 v3.0.0
go get: github.com/upyun/go-sdk/[email protected]: verifying module: checksum mismatch
downloaded: h1:Qx/6C961SOicM/+a7PJW8K+e/0WLnwTZ9qfKFD/RnGQ=
sum.golang.org: h1:AXmeuTWJp3oZUjXX/45RssJTndcxAbvGZqtsgKxuMIM=

SECURITY ERROR
This download does NOT match the one reported by the checksum server.
The bits may have been replaced on the origin server, or an attacker may
have intercepted the download attempt.

For more information, see 'go help module-auth'.

// Get dir info list 
info, err := u.GetList("/foo")

当 /foo 文件夹为空时，运行直接报错:

panic: runtime error: index out of range

goroutine 1 [running]:
github.com/upyun/go-sdk/upyun.newInfo(0x436bf0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
    /Users/arron/Documents/go_workspace/src/github.com/upyun/go-sdk/upyun/upyun.go:164 +0x189
github.com/upyun/go-sdk/upyun.(*UpYun).GetList(0xc208054060, 0x2d9170, 0x8, 0x0, 0x0, 0x0, 0x0, 0x0)
    /Users/arron/Documents/go_workspace/src/github.com/upyun/go-sdk/upyun/upyun.go:450 +0x254
main.main()
    /Users/arron/Documents/go_workspace/src/go_upyun/go_upyun.go:29 +0x453

goroutine 8 [select]:
net/http.(*persistConn).readLoop(0xc2080680b0)
    /usr/local/go/src/net/http/transport.go:928 +0x9ce
created by net/http.(*Transport).dialConn
    /usr/local/go/src/net/http/transport.go:660 +0xc9f

goroutine 17 [syscall, locked to thread]:
runtime.goexit()
    /usr/local/go/src/runtime/asm_amd64.s:2232 +0x1

goroutine 9 [select]:
net/http.(*persistConn).writeLoop(0xc2080680b0)
    /usr/local/go/src/net/http/transport.go:945 +0x41d
created by net/http.(*Transport).dialConn
    /usr/local/go/src/net/http/transport.go:661 +0xcbc

goroutine 12 [IO wait]:
net.(*pollDesc).Wait(0xc208010610, 0x72, 0x0, 0x0)
    /usr/local/go/src/net/fd_poll_runtime.go:84 +0x47
net.(*pollDesc).WaitRead(0xc208010610, 0x0, 0x0)
    /usr/local/go/src/net/fd_poll_runtime.go:89 +0x43
net.(*netFD).Read(0xc2080105b0, 0xc208059000, 0x1000, 0x1000, 0x0, 0x1011b08, 0xc20800af40)
    /usr/local/go/src/net/fd_unix.go:242 +0x40f
net.(*conn).Read(0xc20802c0b0, 0xc208059000, 0x1000, 0x1000, 0x0, 0x0, 0x0)
    /usr/local/go/src/net/net.go:121 +0xdc
net/http.noteEOFReader.Read(0x1012e18, 0xc20802c0b0, 0xc208068268, 0xc208059000, 0x1000, 0x1000, 0xc20802a2c0, 0x0, 0x0)
    /usr/local/go/src/net/http/transport.go:1270 +0x6e
net/http.(*noteEOFReader).Read(0xc20801eb00, 0xc208059000, 0x1000, 0x1000, 0xc208012000, 0x0, 0x0)
    <autogenerated>:125 +0xd4
bufio.(*Reader).fill(0xc208054cc0)
    /usr/local/go/src/bufio/bufio.go:97 +0x1ce
bufio.(*Reader).Peek(0xc208054cc0, 0x1, 0x0, 0x0, 0x0, 0x0, 0x0)
    /usr/local/go/src/bufio/bufio.go:132 +0xf0
net/http.(*persistConn).readLoop(0xc208068210)
    /usr/local/go/src/net/http/transport.go:842 +0xa4
created by net/http.(*Transport).dialConn
    /usr/local/go/src/net/http/transport.go:660 +0xc9f

goroutine 13 [select]:
net/http.(*persistConn).writeLoop(0xc208068210)
    /usr/local/go/src/net/http/transport.go:945 +0x41d
created by net/http.(*Transport).dialConn
    /usr/local/go/src/net/http/transport.go:661 +0xcbc
exit status 2

Hi, thanks for the excellent library! I am wondering whether you are interested in adding the purge component to the library? I wrote a simple one a couple of days ago based on your code. Could you please take a look at the code?

master...luanzhu:for-upyunpurge-pull-request

I will be more than happy to create a pull request if you like to include the purge component?

Thanks a lot!

p1.api.upyun.com//snapshot

通过url直接上传文件到UPYUN, 无需下载到本地再通过文件上传!
比如我在浏览网页时发现喜爱的图片, 想存储在UPYUN空间, 亦或者我在网页上需要下载一个大文件, 又想将这个文件存储在又拍云! 提供这个接口可以略去将资源下载到本地的步骤, 直接将资源存储到UPYUN
可复用接口func (u *UpYun) Get(key string, value *os.File) error, 使 value即可以接收os.File, 又可以接收url(interface{}可实现)!

我不知道是什么情况，是业务上就不支持中文名称还是需要经过加工上传？我是将路径名称经过md5再上传的，英文名称的文件能够通过上传

golang sdk 源码有个bug。重复base64加密policy，导致签名signature md5加密后鉴权失败。

使用Put方法上传图片之后（使用文件字节流上传），无法通过GetInfo方法获取图片的具体信息，图片是正常上传的，GetInfo只能获取到大小，但是无法获取宽高等其他信息

在readme中，示例写的是：

u := upyun.NewUpYun("bucket", "username", "password")

我使用了我注册时的username 和password结果验证不通过401,后来使用了创建的操作员的用户名和密码才通过。
所以这里应该改一下吧：

u := upyun.NewUpYun("bucket", "operator_name", "operator_pwd")

是否支持对象存储签名url， sdk找不到方法

Background

The github.com/upyun/go-sdk uses Go modules and the current release version is v2. And it’s module path is "github.com/upyun/go-sdk", instead of "github.com/upyun/go-sdk/v2". It must comply with the specification of "Releasing Modules for v2 or higher" available in the Modules documentation. Quoting the specification:

A package that has opted in to modules must include the major version in the import path to import any v2+ modules
To preserve import compatibility, the go command requires that modules with major version v2 or later use a module path with that major version as the final element. For example, version v2.0.0 of example.com/m must instead use module path example.com/m/v2.
https://github.com/golang/go/wiki/Modules#releasing-modules-v2-or-higher

Steps to Reproduce

GO111MODULE=on, run go get targeting any version >= v2.2.0 of the upyun/go-sdk:

$ go get github.com/upyun/[email protected]
go: finding github.com/upyun/go-sdk v2.2.0
go: finding github.com/upyun/go-sdk v2.2.0
go get github.com/upyun/[email protected]: github.com/upyun/[email protected]: invalid version: module contains a go.mod file, so major version must be compatible: should be v0 or v1, not v2

run go get github.com/upyun/go-sdk, the version will stuck in v2.1.0:

$go get github.com/upyun/go-sdk
go: downloading github.com/upyun/go-sdk v1.1.1
go: github.com/upyun/go-sdk upgrade => v2.1.0+incompatible 

SO anyone using Go modules will not be able to easily use any newer version of upyun/go-sdk.

Solution

1. Kill the go.mod files, rolling back to GOPATH.

This would push them back to not being managed by Go modules (instead of incorrectly using Go modules).
Ensure compatibility for downstream module-aware projects and module-unaware projects projects

I see these dependencies in your go.mod file, which need modle awareness. So you'd better not use third-party tools(such as: Dep, glide, govendor…).

github.com/casbin/casbin/v2 v2.4.1
github.com/urfave/cli/v2

You also need to update the import path to:

import github.com/casbin/casbin/…
import github.com/urfave/cli/…

2. Fix module path to strictly follow SIV rules.

Patch the go.mod file to declare the module path as github.com/upyun/go-sdk/v2 as per the specs. And adjust all internal imports.
The downstream projects might be negatively affected in their building if they are module-unaware (Go versions older than 1.9.7 and 1.10.3; Or use third-party dependency management tools, such as: Dep, glide,govendor…).

[*] You can see who will be affected here: [3 module-unaware users, i.e., ziyeziye/CloudStore, TruthHun/CloudStore, xEasy/baker ]
https://github.com/search?q=upyun%2Fgo-sdk+filename%3AGodeps.json+filename%3Avendor.conf+filename%3Avendor.json+filename%3Aglide.toml+filename%3AGodep.toml&type=Code

If you don't want to break the above repos. This method can provides better backwards-compatibility.
Release a v2 or higher module through the major subdirectory strategy: Create a new v2 subdirectory (github.com/upyun/go-sdk/v2) and place a new go.mod file in that subdirectory. The module path must end with /v2. Copy or move the code into the v2 subdirectory. Update import statements within the module to also use /v2 (import "github.com/upyun/go-sdk/v2/…"). Tag the release with v2.x.y.

3. Major version bump / repository change

Leave v2 as a dead version and bump to v3 with the path changes.

4. Suggest your downstream module users to use hash instead of a version tag.

If the standard rule of go modules conflicts with your development mode. Or not intended to be used as a library and does not make any guarantees about the API. So you can’t comply with the specification of "Releasing Modules for v2 or higher" available in the Modules documentation.
Regardless, since it's against one of the design choices of Go, it'll be a bit of a hack. Instead of go get github.com/upyun/go-sdk@version-tag, module users need to use this following way to get the upyun/go-sdk:
(1) Search for the tag you want (in browser)
(2) Get the commit hash for the tag you want
(3) Run go get github.com/upyun/go-sdk@commit-hash
(4) Edit the go.mod file to put a comment about which version you actually used
This will make it difficult for module users to get and upgrade upyun/go-sdk.

[*] You can see who will be affected here: [28 module users, e.g., cilidm/mybed, alexlueng/invoicing, kekwl/Cloudreve]
https://github.com/search?q=upyun%2Fgo-sdk+filename%3Ago.mod&type=Code

Summary

You can make a choice to fix DM issues by balancing your own development schedules/mode against the affects on the downstream projects.

For this issue, Solution 2 can maximize your benefits and with minimal impacts to your downstream projects the ecosystem.

References

• https://github.com/golang/go/wiki/Modules#semantic-import-versioning
• https://golang.org/cmd/go/#hdr-Module_compatibility_and_semantic_versioning
• https://github.com/golang/go/wiki/Modules#releasing-modules-v2-or-higher

https://github.com/upyun/go-sdk/blob/master/upyun/rest.go#L641
如果我想手动的进行 list 分页操作，现在这样的实现会导致我无法继续 list 剩余的文件。因为在 return 的时候还没有设置 "X-List-Iter" 这个 header