Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmd/go: yet another case where time stamps lead us astray #5064

Closed
4a6f656c opened this issue Mar 17, 2013 · 11 comments
Closed

cmd/go: yet another case where time stamps lead us astray #5064

4a6f656c opened this issue Mar 17, 2013 · 11 comments

Comments

@4a6f656c
Copy link
Contributor

When building packages outside of the GOROOT (i.e. GOPATH != GOROOT), go may still
attempt to rebuild packages in the GOROOT if they depend on a package in the GOROOT that
appears to be stale.

This is easily reproduced as follows:

$ sudo tar -C /usr/local -xzf go1.0.3.linux-amd64.tar.gz
$ sudo touch /usr/local/go/pkg/linux_amd64/reflect.a
$ echo $GOPATH
/home/jsing/src/mygo
$ cat example/example.go 
package example

import _ "encoding/binary"
$ go install example
go install encoding/binary: open /usr/local/go/pkg/linux_amd64/encoding/binary.a:
permission denied

In the above case, encoding/binary is marked as stale and go attempts to rebuild it
since reflect is considered stale, even though encoding/binary is under the GOROOT. This
results in problems when users are not able to write to GOROOT; the packaging comments
from issue/4106 are also applicable here.
@rsc
Copy link
Contributor

rsc commented Mar 19, 2013

Comment 1:

Sorry, but we can't fix this before Go 1.1. It's too late to be rethinking this logic
yet again.
I suggest that we update the docs to tell people to tell tar to preserve time stamps
from the archive.

Labels changed: added priority-someday, removed priority-triage.

@minux
Copy link
Member

minux commented Mar 19, 2013

Comment 2:

could we sort the files by their mtime when creating the tar
so that even if the extracting tar does not preserve timestamp
the timestamps are still  ok?

@rsc
Copy link
Contributor

rsc commented Mar 19, 2013

Comment 3:

That's probably not good enough. We wouldn't know the ordering for two
files with the same time, yet there may still be an order.

@rsc
Copy link
Contributor

rsc commented Jul 30, 2013

Comment 4:

Labels changed: added go1.2maybe.

@rsc
Copy link
Contributor

rsc commented Jul 30, 2013

Comment 5:

Labels changed: added feature.

@robpike
Copy link
Contributor

robpike commented Aug 20, 2013

Comment 6:

Deferring to 1.3.

Labels changed: added go1.3maybe, removed go1.2maybe.

@robpike
Copy link
Contributor

robpike commented Aug 20, 2013

Comment 7:

Labels changed: removed go1.3maybe.

@rsc
Copy link
Contributor

rsc commented Dec 4, 2013

Comment 8:

Labels changed: added repo-main.

@rsc
Copy link
Contributor

rsc commented Mar 3, 2014

Comment 9:

Adding Release=None to all Priority=Someday bugs.

Labels changed: added release-none.

@gopherbot
Copy link

Comment 10 by alexsanami:

You mention this was fixed in the following revision:
https://code.google.com/p/go/source/detail?r=28e51505db8a
However, I can reproduce this and it is still in an issue.  Can you clarify what has
been fixed and if you have any plans to resolve this problem or potential workarounds.

@rsc
Copy link
Contributor

rsc commented Apr 20, 2015

I don't understand what this bug is about anymore, especially given the work that has gone into the go command since it was originally filed. If something is not working for you, please create a new issue explaining exactly how to reproduce.

The original report in this issue appears to have been fixed by commit b03a5f6, a year before the report. Again, please file a new issue with details if some specific case is not working for you today (using Go 1.4).

@rsc rsc closed this as completed Apr 20, 2015
@golang golang locked and limited conversation to collaborators Jun 24, 2016
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

5 participants