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

os: no direct access to file access time #3952

Closed
gopherbot opened this issue Aug 15, 2012 · 12 comments
Closed

os: no direct access to file access time #3952

gopherbot opened this issue Aug 15, 2012 · 12 comments

Comments

@gopherbot
Copy link

@gopherbot gopherbot commented Aug 15, 2012

by coolaj86:

os.Chtimes sets atime and mtime (but not ctime??), yet only func (info FileInfo)
ModTime() can be accessed, not the atime.

What steps will reproduce the problem?

Read the documentation

What is the expected output?

I should be able to do a set / get test on os.Chtimes

What do you see instead?

I can't test it because it sets data that can't be read

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')

1.0.2

Please provide any additional information below.
@remyoudompheng

This comment has been minimized.

Copy link
Contributor

@remyoudompheng remyoudompheng commented Aug 15, 2012

Comment 1:

To access the full, OS-specific file information you are supposed to use
fileinfo.Sys().(*syscall.Stat_t) (this is on Linux and maybe other Unix-likes)
I suppose more OS-independant methods can be added to os.FileInfo if they make sense.
@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Aug 15, 2012

Comment 2:

The access time is not available because the Windows os.Stat does not return it.  I
don't know Windows at all.  If the Windows Stat can return it, then we can add AccTime
to the FileInfo interface.  Otherwise it will need to be system dependent per previous
comment.

Labels changed: added os-windows.

@alexbrainman

This comment has been minimized.

Copy link
Member

@alexbrainman alexbrainman commented Aug 15, 2012

Comment 3:

I could be wrong, but the access time should be available on windows. In fact, looking
at the code, we already have
func atime(fi FileInfo) time.Time
implemented in os. It is used for os tests only, but we could expose this functionality.
If someone wants to suggest the interface, I am happy to implement and test windows side
of things.
Alex
@rsc

This comment has been minimized.

Copy link
Contributor

@rsc rsc commented Sep 12, 2012

Comment 4:

Plenty of systems don't support access time. I believe that is why it is not part of the
FileInfo API.
We cannot add anything to os.FileInfo, because of the Go 1 promise.
The idea is that if you care, you use .Sys() and then you know you're doing something
system-specific.

Status changed to WorkingAsIntended.

@gopherbot

This comment has been minimized.

Copy link
Author

@gopherbot gopherbot commented Dec 18, 2012

Comment 5 by cpisto:

Definitely seems odd that you can *set* access time via os.Chtimes, but then there is no
way to *get* the same value.
@gopherbot

This comment has been minimized.

Copy link
Author

@gopherbot gopherbot commented Dec 18, 2012

Comment 6 by cpisto:

Additionally, on windows, you can't actually use .Sys() because it returns an unexported
struct type and not a syscall. type.
@alexbrainman

This comment has been minimized.

Copy link
Member

@alexbrainman alexbrainman commented Dec 18, 2012

Comment 7:

cpisto,
We can change what .Sys() returns on windows to provide whatever functionality you need.
We could have LastAccessTime and CreationTime, if you like. What do you think?
Alex
@gopherbot

This comment has been minimized.

Copy link
Author

@gopherbot gopherbot commented Dec 18, 2012

Comment 8 by cpisto:

I think having .Sys() on windows work as similar as possible to the other platforms
would be ideal.
Looking at the code though, that looks to be a bit complicated.
It looks like FileInfo.Sys() from a FileInfo returned by os.Stat could easily return a
syscall.Win32FileAttributeData, however, File.Stat would need to use a
syscall.ByHandleFileInformation. As this is a platform specific implementation detail, I
would not be opposed to Sys() returning either, and the caller being responsible for
determining if its supposed to be a Win32FileAttributeData or ByHandleFileInformation
via reflect or the like.
Does something else make more sense?
@gopherbot

This comment has been minimized.

Copy link
Author

@gopherbot gopherbot commented Dec 18, 2012

Comment 9 by cpisto:

FileInfo.Sys() returned from a Readdir would be a syscall.Win32finddata.
@alexbrainman

This comment has been minimized.

Copy link
Member

@alexbrainman alexbrainman commented Dec 18, 2012

Comment 10:

> I think having .Sys() on windows work as similar as possible to the other platforms
would be ideal.
How so? For example, it looks like this on linux:
type Stat_t struct {
    Dev       uint64
    X__pad1   uint16
    Pad_cgo_0 [2]byte
    X__st_ino uint32
    Mode      uint32
    Nlink     uint32
    Uid       uint32
    Gid       uint32
    Rdev      uint64
    X__pad2   uint16
    Pad_cgo_1 [2]byte
    Size      int64
    Blksize   int32
    Blocks    int64
    Atim      Timespec
    Mtim      Timespec
    Ctim      Timespec
    Ino       uint64
}
Do you want it all on windows? I do not think so.
> It looks like FileInfo.Sys() from a FileInfo returned by os.Stat could easily ...
Lets not design things here. Just tell use what you need. What is your problem?
Once we know what your problem is, then, perhaps, we can decide how to help you.
Thank you.
Alex
@gopherbot

This comment has been minimized.

Copy link
Author

@gopherbot gopherbot commented Dec 19, 2012

Comment 11 by cpisto:

Cool, all I need is LastAccessTime and CreationTime.
Thanks
@alexbrainman

This comment has been minimized.

Copy link
Member

@alexbrainman alexbrainman commented Dec 19, 2012

Comment 12:

Moving discussion here https://golang.org/issue/4569
Alex
@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.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants
You can’t perform that action at this time.