Bug 1378 - support full 100uS time stamps on those OSes that support 64-bit timestamps
Summary: support full 100uS time stamps on those OSes that support 64-bit timestamps
Status: RESOLVED FIXED
Alias: None
Product: Samba 3.0
Classification: Unclassified
Component: File Services (show other bugs)
Version: 3.0.0preX
Hardware: Other All
: P2 enhancement
Target Milestone: none
Assignee: Samba Bugzilla Account
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-05-24 16:22 UTC by Richard Sharpe
Modified: 2009-02-12 10:37 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Richard Sharpe 2004-05-24 16:22:39 UTC
Some file systems support 64-bit time stamps and have the utimes system call.
This includes at least FreeBSD 4.6 and above and Linux.

However, Samba does not pass the actual Windows timestamp values down to the VFS
layer.

I imagine that we will need configure tests to detect if 64-bit timestamps are
supported on the platform that Samba is being built for, as well as changes to
pass 64-bit time stamps all the way down.

In addition, it might be useful to pass all four time stamps that Windows gives
us down to the VFS layer on the grounds that some implementations might be able
to store all four timestamps, or will choose to store some in extended attributes.
Comment 1 John Malmberg 2004-10-06 18:24:20 UTC
OpenVMS uses 64 bit timestamps, but on VAX would prefer them to be passed by
pointer, not by value, as VAX does not support any 64 bit integer types.

It would be better on OpenVMS if there were a set of macros that could be
overridden by CONFIG.H that would allow the conversion from the SAMBA host times
directly to the Microsoft Windows times, as there would be no loss in precision
from the conversion.

For the VFS layer, OpenVMS can store/report several of the timestamps with the
same precision as Microsoft Windows.

Otherwise for OpenVMS, the conversion to a what the OpenVMS C support library
stores as a UNIX timestamp involves a loss of precision the last time I checked
the options available.
Comment 2 Gerald (Jerry) Carter (dead mail address) 2005-02-07 08:36:19 UTC
anyone going to work on this ?
Comment 3 Björn Jacke 2009-02-12 10:37:23 UTC
this is done