Kristaps Dzonsons wrote:
> >> ... it says the modification time is a time_t. Which means we only
> >> have seconds, not subseconds.
> >
> > Fair enough. The protocol predates common availability of nanosecond
> > file timestamps.
>
> It's worse than that. It's 32-bit time_t.
Your docs say
Kristaps Dzonsons wrote:
> >> ... it says the modification time is a time_t. Which means we only
> >> have seconds, not subseconds.
> >
> > Fair enough. The protocol predates common availability of nanosecond
> > file timestamps.
>
> It's worse than that. It's 32-bit time_t.
Do negative
>> ... it says the modification time is a time_t. Which means we only
>> have seconds, not subseconds.
>
> Fair enough. The protocol predates common availability of nanosecond
> file timestamps.
It's worse than that. It's 32-bit time_t.
On Fri, 22 Mar 2019 11:16:00 -0500, Scott Cheloha wrote:
> ... it says the modification time is a time_t. Which means we only
> have seconds, not subseconds.
Fair enough. The protocol predates common availability of nanosecond
file timestamps.
- todd
On Fri, Mar 22, 2019 at 10:10:43AM -0600, Todd C. Miller wrote:
> On Fri, 22 Mar 2019 11:04:05 -0500, Scott Cheloha wrote:
>
> > I always forget about the special value shortcut for utimes(2) et al.
> >
> > This is equivalent/simpler/more portable.
>
> That looks good but I wonder why we are not
On Fri, 22 Mar 2019 11:04:05 -0500, Scott Cheloha wrote:
> I always forget about the special value shortcut for utimes(2) et al.
>
> This is equivalent/simpler/more portable.
That looks good but I wonder why we are not preserving the nanosecond
mtime by using st_mtim?
- todd
I always forget about the special value shortcut for utimes(2) et al.
This is equivalent/simpler/more portable.
ok?
Index: receiver.c
===
RCS file: /cvs/src/usr.bin/rsync/receiver.c,v
retrieving revision 1.19
diff -u -p -r1.19
