os: no direct access to file access time

[gopherbot]

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]

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]

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]

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]

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]

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]

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]

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]

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]

Comment 9 by cpisto:

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

[alexbrainman]

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]

Comment 11 by cpisto:

Cool, all I need is LastAccessTime and CreationTime.
Thanks

[alexbrainman]

Comment 12:

Moving discussion here https://golang.org/issue/4569
Alex