Bug 7771 - NTTIME cannot set/get dates before 1/1/1970
Summary: NTTIME cannot set/get dates before 1/1/1970
Alias: None
Product: Samba 4.0
Classification: Unclassified
Component: Other (show other bugs)
Version: unspecified
Hardware: All All
: P3 normal (vote)
Target Milestone: ---
Assignee: Ralph Böhme
QA Contact: samba4-qa@samba.org
: 10802 (view as bug list)
Depends on:
Reported: 2010-11-02 12:02 UTC by Milan Crha
Modified: 2021-05-24 10:03 UTC (History)
4 users (show)

See Also:


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:

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:

> /* 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

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.

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.
Comment 10 Ralph Böhme 2019-11-20 16:36:25 UTC
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.
Comment 11 Ralph Böhme 2020-01-16 18:51:50 UTC
Fixed for 4.12