Displaying 4 results from an estimated 4 matches for "bwag_r2_00086400".
2016 Jun 09
4
rsync keeps writing files over
...n means the create time (newness)
is different and is being updated to the sender's value (requires
--crtimes).
(I¹m not quite sure I completely understand ‹-modify-window)
Here is a <dest> file example of timestamps as rsync interprets them:
-rwxrwxrwx 24,839,552 2016/06/08 13:13:19 BWAG_R2_00086400.dpx
Here is a <src> file example of timestamps as rsync interprets them:
-rwxrwxrwx 24,839,552 2016/05/27 13:43:32 BWAG_R2_00086400.dpx
So, yeah, that is the problem, apparently. The timestamps are
transferring.
But, for the files that have the ³n² the timestamps appear to be fine a...
2016 Jun 11
0
rsync keeps writing files over
...#39;s filesystem that had 2-second
timestamp resolution from a *ix system with 1-second resolution, you would
need to use --modify-window=2 to avoid spurious transfers.
>Here is a <dest> file example of timestamps as rsync interprets them:
>-rwxrwxrwx 24,839,552 2016/06/08 13:13:19 BWAG_R2_00086400.dpx
>Here is a <src> file example of timestamps as rsync interprets them:
>-rwxrwxrwx 24,839,552 2016/05/27 13:43:32 BWAG_R2_00086400.dpx
Without --times, this is the expected behavior. The timestamps differ, so
rsync will transfer the file. Because the file content is the same,...
2016 Jun 09
0
rsync keeps writing files over
...ss)
> is different and is being updated to the sender's value (requires
> --crtimes).
> (I¹m not quite sure I completely understand ‹-modify-window)
>
> Here is a <dest> file example of timestamps as rsync interprets them:
> -rwxrwxrwx 24,839,552 2016/06/08 13:13:19 BWAG_R2_00086400.dpx
>
> Here is a <src> file example of timestamps as rsync interprets them:
> -rwxrwxrwx 24,839,552 2016/05/27 13:43:32 BWAG_R2_00086400.dpx
>
>
>
> So, yeah, that is the problem, apparently. The timestamps are
> transferring.
>
> But, for the files th...
2016 Jun 02
9
rsync keeps writing files over
Cool Thanks!
Specifically, the timestamps on both <src> and <dest> match for "ls -l"
but do not match for "ls -lu" or "ls -lc”
The storage is just an regular HDD in a mac pro tower. I can’t imagine why
it wouldn’t handle timestamps. Also of note - this problem doesn’t exist
for every file, just the vast majority. So, that just makes it more
confusing.
Yes,