Skip to content
This repository has been archived by the owner on Sep 9, 2020. It is now read-only.

vendor.orig causes subsequent dep ensure's to explode #1304

Closed
davecheney opened this issue Oct 24, 2017 · 3 comments · Fixed by #1309
Closed

vendor.orig causes subsequent dep ensure's to explode #1304

davecheney opened this issue Oct 24, 2017 · 3 comments · Fixed by #1309

Comments

@davecheney
Copy link
Contributor

davecheney commented Oct 24, 2017

What version of dep are you using (dep version)?

v0.3.1-122-g98f625e

What dep command did you run?

dep ensure -v
^C
dep ensure -v

What did you expect to see?

Normal dep ensure stuff

What did you see instead?

% dep ensure -v                                                                                                                                                                                        
found 170 errors in the package tree:
import root "github.com/heptio/zzz" is not a prefix for the package's declared canonical path "golang.org/x/crypto/ssh/testdata"
import root "github.com/heptio/zzz" is not a prefix for the package's declared canonical path "golang.org/x/oauth2/paypal"
import root "github.com/heptio/zzz" is not a prefix for the package's declared canonical path "golang.org/x/crypto/openpgp/elgamal"

and on and on and on for pages

This was caused by the vendor.orig/ folder left around by the first dep ensure which was canceled.

Dep should abort if it finds this folder, or at least ignore it.

@sdboyer
Copy link
Member

sdboyer commented Oct 24, 2017

hmm, yeah, we have a deeper problem here, which is needing to do signal handling at a higher level (in dep, rather than gps directly), then we need to plumb context through the various fs funcs in order to achieve safe aborts. THEN link all that together with the context being plumbed more thoroughly through the solver in #1230.

that's a fair bit of work. in the meantime, though, we should be able to handle this scenario more sanely with some basic guards in place.

@sdboyer
Copy link
Member

sdboyer commented Oct 24, 2017

...actually, sorry, i misread this. i thought that you were seeing errors because it was tripping on the vendor.orig when trying to write a new vendor dir. that's not the case - it's that dep isn't ignoring the vendor.orig dir on subsequent runs.

this is where we pick that temporary location for the current vendor:

dep/txn_writer.go

Lines 378 to 388 in df32e15

// Move out the old vendor dir. just do it into an adjacent dir, to
// try to mitigate the possibility of a pointless cross-filesystem
// move with a temp directory.
vendorbak = vpath + ".orig"
if _, err := os.Stat(vendorbak); err == nil {
// If the adjacent dir already exists, bite the bullet and move
// to a proper tempdir.
vendorbak = filepath.Join(td, "vendor.orig")
}
failerr = fs.RenameWithFallback(vpath, vendorbak)

with recent changes, we're now fine if we just change that dirname slightly, to .vendor.orig - it'll be ignored on subsequent runs - no more errors. still not the ideal solution, but it at least won't interfere with dep's operation.

making a PR now.

sdboyer added a commit to sdboyer/dep that referenced this issue Oct 24, 2017
While there's more work to be done in making all of this safe in the
event of a signal being sent to dep, this change at least means that if
a signal is sent during the rename and a .vendor.orig directory is left
behind, subsequent runs will treat its contents as ignored.

Fixes golang#1304
@davecheney
Copy link
Contributor Author

davecheney commented Oct 25, 2017 via email

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants