8000 os.Chtimes follows symlinks · Issue #3951 · golang/go · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

os.Chtimes follows symlinks #3951

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.

Sign up for GitHub

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
Closed
gopherbot opened this issue Aug 15, 2012 · 8 comments
Closed

os.Chtimes follows symlinks #3951

gopherbot opened this issue Aug 15, 2012 · 8 comments
Labels
FrozenDueToAge

Comments

@gopherbot
Copy link
Contributor

by coolaj86:

http://play.golang.org/p/IHpp9SgxS9

What is the expected output?

Chtimes will change the time of the file I specify

What do you see instead?

In some cases it appears that the time is being set on the target of the symlink, in
other cases it appears that neither is being set.

Which compiler are you using (5g, 6g, 8g, gccgo)?

go run

Which operating system are you using?

OS X 10.8

Which version are you using?  (run 'go version')

go version go1.0.2

Please provide any additional information below.
@ianlancetaylor
Copy link
Contributor

Comment 1:

os.Chtimes simply calls the utimes system call.  If there is an oddity here, I don't
think it is on the Go side.
Looking at your program, you should check the error return of ioutil.WriteFile and
os.Symlink.

Labels changed: added os-macosx.

@minux
Copy link
Member
minux commented Aug 15, 2012

Comment 2:

FYI, using setattrlist(2) on Darwin could change the timestamp of the
symlink file itself.
utimes(2) will always follow symlinks on Darwin, AFAIK.
what's missing is perhaps we mention this in the document of os.Chtimes.
(imo, we shouldn't document this system dependent behavior.)

@ianlancetaylor
Copy link
Contributor

Comment 3:

Would Darwin work correctly if we used the POSIX utime system call rather than the older
utimes call?

@minux
Copy link
Member
minux commented Aug 15, 2012

Comment 4:

afaik, on Darwin, utime(3) is emulated by utimes(2).
(xnu kernel doesn't contain the utime syscall, and POSIX only defines the API,
so this is OK)
i think to update timestamp of symlinks, we need to use setattrlist(2),
and this is what touch(1) in GNU coreutils does.
can we change behavior of os.Chtimes now? or put it another way, is this
issue really a bug?

@ianlancetaylor
Copy link
Contributor

Comment 5:

I think this is a bug but I don't think it's a very important one.  At the os level we
should aim for similar behaviour across systems to the extent that that is possible. 
Since it is apparently possible on Darwin, we should aim for it.

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

Status changed to Accepted.

@minux
Copy link
Member
minux commented Aug 15, 2012

Comment 6:

we're also using utimes(2) on all posix systems (unix and windows), so i think
this bug also affects other systems beside Darwin.
for example, on Linux, we need to use utimensat(2) and set AT_SYMLINK_NOFOLLOW
as flags.
in this regard, the current behavior might be actually consistent.

@ianlancetaylor
Copy link
Contributor

Comment 7:

If the behaviour is consistent across systems then I don't think there is a bug here.

@rsc
Copy link
Contributor
rsc commented Sep 12, 2012

Comment 8:

I don't believe this is a bug. Symlinks (as opposed to their targets) are very hard to
manipulate directly.

Status changed to WorkingAsIntended.

@golang golang locked and limited conversation to collaborators Jun 24, 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
No milestone
Development

No branches or pull requests
4 participants
@rsc @minux @ianlancetaylor @gopherbot
0