Samba, buggy access time modification and me on lldb

I've been looking at a bug in Samba that changes the atime of files to 
something silly in the future caused by a poorly undocumented feature of NT.

(The original problem is a customer with Solidworks that creates and is 
unhappy with such future files.)

This is the bug https://bugzilla.samba.org/show_bug.cgi?id=14127

On my machine I can use Windows Explorer to create a new Microsoft Excel 
Worksheet to create a file with an access time of 2038 (0x7fffffff 
seconds). This happens on both ZFS and UFS with default mount options.

I can manually apply that patch in the page referenced above until a 
newer port comes along.

However what really upsets me is that I have been unable to spot Samba 
issuing the offending system call.

I believe only the utime family of calls that can do this and Samba only 
uses utimensat. I have searched the code and used both ktruss and dtrace 
to verify this is the case.

So I have this lldb breakpoint

br s -n utimensat -c '* (long *) ($rdx +16) > 1658852149 || * (long *) 
($rdx +16) < 0'

(and three other similar ones from before I had worked out what syscalls 
actually take place)

which doesn't trigger. I have also had it print * (long *) ($rdx +16) 
which prints only sensible values.

My questions are:

1) As I doing something stupid with lldb or is another syscall used ?

2) With #define NTTIME_THAW ((uint64_t) -2) how did we end up with a 
32-bit 0x7fffffff ?

Thanks,

Jon