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.
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.
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.
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.
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?
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.
*** Bug 10802 has been marked as a duplicate of this bug. ***
I discussed this with Metze. We have a preliminary plan to fix this for the file server only. Jeremy.
and that is how?
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.
Looking into this... The bigger problem seems to be replacing the null_timespec() logic that is used all over the place to detect timestamps that should be ignored. As struct timespec {0} and time_t(0) are perfectly valid timestamps in the filesytem, I guess I'll try to fix the time_t = 0 case as well as the time_t < 0 case. The good thing is, that we may be able to reuse the utimensat logic where struct timespec.tv_nsec = UTIME_OMIT denotes a to be ignored timestamp.
Fixed for 4.12