Bug 7771 - NTTIME cannot set/get dates before 1/1/1970
NTTIME cannot set/get dates before 1/1/1970
Status: NEW
Product: Samba 4.0
Classification: Unclassified
Component: Other
unspecified
All All
: P3 normal
: ---
Assigned To: Björn Jacke
samba4-qa@samba.org
:
: 10802 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-11-02 12:02 UTC by Milan Crha
Modified: 2015-01-30 18:23 UTC (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Milan Crha 2010-11-02 12:02:09 UTC
As reported in Gnome's bugzilla against evolution-mapi:
https://bugzilla.gnome.org/show_bug.cgi?id=633185

the NTTIME routines cannot get/set dates before 1/1/1970.
Comment 1 Matthias Dieter Wallnöfer 2010-11-03 16:49:46 UTC
By the definition this should work:

lib/util/time.h
===============
> /* 64 bit time (100 nanosec) 1601 - cifs6.txt, section 3.5, page 30, 4 byte aligned */
> typedef uint64_t NTTIME;

Please explain a bit in which codepath this doesn't work in order to allow a bugfix.
Comment 2 Björn Jacke 2010-11-03 17:05:09 UTC
also from lib/util/time.h:

#ifndef TIME_T_MIN
/* we use 0 here, because (time_t)-1 means error */
#define TIME_T_MIN 0
#endif

TIME_T_MIN isn't predefined on most systems, so with this 1970-01-01 is the lower end of supported time supported by Samba. It would be cool if we could support the full range of the system's unsigned time_t range. Most problematic are the special cases of UNIX time "0" and "-1", which have special meaning at several places inside Samba. I think the rest of the negative time_t range could be used theoretically with some tweaking.
Comment 3 Milan Crha 2010-11-04 05:04:45 UTC
Yes, the problem is that you have max and min for time_t, but you should only treat those special values (I didn't know of 0, but I know of -1).

Basically using nt_time_to_unix, nttime_to_timeval and unix_to_nt_time (and most likely others too) clamps the time_t value to your boundaries, though the other values (below 1970) can be safely expressed within time_t as a negative value. My workaround in evolution-mapi is to rewrite your routines to those where the value is not clamped.
Comment 4 Matthias Dieter Wallnöfer 2010-11-04 10:40:06 UTC
Björn, would you take care about this patch? Should I assign it up to you?
And then, should we keep it under Samba 4 or would you like to have it under Samba 3.6?
Comment 5 Björn Jacke 2010-11-08 04:30:55 UTC
I'll take the ticket as I have that topic on my personal todo list. I'm not sure about the time frame for the fixing, so if someone else wants to look into that, feel free to do so, too.
It's to be fixed mainly in shared code, so it doesn't matter if it's 4.0 or 3.x in bugzilla.
Comment 6 Björn Jacke 2014-09-08 07:39:02 UTC
*** Bug 10802 has been marked as a duplicate of this bug. ***
Comment 7 Jeremy Allison 2014-09-16 00:40:22 UTC
I discussed this with Metze. We have a preliminary plan to fix this for the file server only.

Jeremy.
Comment 8 Björn Jacke 2014-09-16 13:16:16 UTC
and that is how?
Comment 9 Jeremy Allison 2014-09-16 16:05:03 UTC
Start by splitting off the fileserver get/set date code to ensure it deals with 64-bit signed values, on 64-bit machines.

Then convert the time_t database schema from int32 -> int64 with a db version update flag day on new release.