On 2012/12/10 23:41:23, brainman wrote:
windows - there
is no such windows syscall.
Also this approach will end up with new public interface
(syscall.UtimesNano as
a minimum) and complicated windows logic (convert from time.Time to
int64 then
to syscall.Timeval in os.Chtimes, then call to syscall.UtimesNano,
then convert
to syscall.Timespec, then convert to int64, then convert to Filetime, then call
syscall).
Why can't we just move os.Chtimes from file_posix.go into file_unix.go and
file_windows.go, Then we could implement whatever needs to be done for windows
in file_windows.go without doing all conversion song and dance.
On 2012/12/10 18:38:15, rsc wrote:
...
It seems fine to write a syscall.UtimesNano that just wraps
syscall.Utimes on the unimplemented systems.
syscall can do a little to be more regular across systems.
I think, there is nothing "regular" about syscall.UtimesNano on...
It seems fine to write a syscall.UtimesNano that just wraps
syscall.Utimes on the unimplemented systems.
syscall can do a little to be more regular across systems.
windows - there
is no such windows syscall.
Also this approach will end up with new public interface
(syscall.UtimesNano as
a minimum) and complicated windows logic (convert from time.Time to
int64 then
to syscall.Timeval in os.Chtimes, then call to syscall.UtimesNano,
then convert
to syscall.Timespec, then convert to int64, then convert to Filetime, then call
syscall).
Why can't we just move os.Chtimes from file_posix.go into file_unix.go and
file_windows.go, Then we could implement whatever needs to be done for windows
in file_windows.go without doing all conversion song and dance.
It certainly seems sensible to me, though I haven't looked at the
details of how hard it would be to divorce it from the posix code yet.
Also what do you think about making it part of this patch set?
https://codereview.appspot.com/6905057/
