Date: Tue, 31 May 2022 11:32:07 +0100 From: Jon Schneider <freebsd@jschneider.net> To: freebsd-questions@FreeBSD.org Subject: Samba, buggy access time modification and me on lldb Message-ID: <11c5c523-2504-6f20-bf15-17f8715395a5@jschneider.net>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?11c5c523-2504-6f20-bf15-17f8715395a5>