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

Jump to bottom

os: Rename on Plan 9 handles newname incorrectly #6401

Closed
gopherbot opened this issue Sep 16, 2013 · 8 comments
Closed

os: Rename on Plan 9 handles newname incorrectly #6401

gopherbot opened this issue Sep 16, 2013 · 8 comments
Labels
FrozenDueToAge
Milestone
Go1.3

Comments

@gopherbot
Copy link

by mischief@offblast.org:

os.Rename on Plan 9 simply does a Wstat, which has some limitations that make its use
behave different than normal use cases.

http://plan9.bell-labs.com/magic/man2html/5/stat

you cannot move a file between directories with os.Rename on plan 9, since it only does
Wstat. to do this you must do a create/copy/remove.

much code appears to expect to be able to pass a full path component in the newname
argument. this fails because you cannot pass a slash to Wstat.

with both of these, code must have a special case for doing renaming operations on plan
9.

os.Rename should probably try to closer match the code in
http://plan9.bell-labs.com/sources/plan9/sys/src/cmd/mv.c
@rsc
Copy link
Contributor

rsc commented Sep 16, 2013

Comment 1:

The handling of newname is definitely wrong. The code must check that the two paths have
the same leading directory and then pass only the final element.
However, the first half of the suggestion is wrong too: os.Rename is allowed to fail for
different directories and on Plan 9 it should. It is a mistake to do the Copy behind the
user's back. os.Rename can fail on Unix too, if the directories are on different file
systems.
Since Plan 9 is not a supported system, this will have to wait until Go 1.3.

Labels changed: added priority-later, go1.3, removed priority-triage.

Status changed to Accepted.

@4ad
Copy link
Member

4ad commented Sep 16, 2013

Comment 2:

I agree with rsc, people use os.Rename for its atomic behavior. We cannot do this in
Plan 9 for as many use cases as for Unix, but we must not lie to the consumer that we
can.

@rsc
Copy link
Contributor

rsc commented Dec 4, 2013

Comment 3:

Labels changed: added release-go1.3.

@rsc
Copy link
Contributor

rsc commented Dec 4, 2013

Comment 4:

Labels changed: removed go1.3.

@rsc
Copy link
Contributor

rsc commented Dec 4, 2013

Comment 5:

Labels changed: added repo-main.

@rsc
Copy link
Contributor

rsc commented Apr 3, 2014

Comment 7:

Plan 9 guys, please fix for Go 1.3 (or maybe it already is?)

@0intro
Copy link
Member

0intro commented Apr 3, 2014

Comment 8:

I missed this issue report. I believe this problem has been fixed in CL 44080046 (and
more recently in CL 65270044).

@ianlancetaylor
Copy link
Contributor

Comment 9:

Thanks.  Closing as fixed, please reopen if it turns out not to be.

Status changed to Fixed.

@rsc rsc added this to the Go1.3 milestone Apr 14, 2015
@rsc rsc removed the release-go1.3 label Apr 14, 2015
@golang golang locked and limited conversation to collaborators Jun 25, 2016
This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge
Projects
None yet
Milestone
Go1.3
Development

No branches or pull requests
5 participants
@rsc @4ad @ianlancetaylor @0intro @gopherbot