[Bug 12819] [PATCH] sync() on receiving side for data consistency

https://bugzilla.samba.org/show_bug.cgi?id=12819 --- Comment #6 from Brian K. White --- Think of it this way, write() already makes a certain promise that it will not return until it's done it's job, and it will not assert success when it can't. Essentially the man page for any

[Bug 12819] [PATCH] sync() on receiving side for data consistency

https://bugzilla.samba.org/show_bug.cgi?id=12819 --- Comment #5 from Brian K. White --- Any program could make this same "just to be safe" argument practically every time they ever close-on-write for any reason. If they wrote anything, it was always for some reason, and they

Re: Bug: rsync erroneously changes modification time

Ok, that clears things up. Thanks. Quoting Paul Slootman via rsync : On Mon 12 Jun 2017, max.power--- via rsync wrote: How exactly does rsync determine that the copy has the incorrect timestamp and not the source file? The source by definition is correct. Paul --

[Bug 12819] [PATCH] sync() on receiving side for data consistency

https://bugzilla.samba.org/show_bug.cgi?id=12819 --- Comment #4 from Ben RUBSON --- Yes Paul I thought about it but sync command may not be available if the server (receiver) is chrooted (for example using patch proposed in #12817). -- You are receiving this mail because:

[Bug 12819] [PATCH] sync() on receiving side for data consistency

https://bugzilla.samba.org/show_bug.cgi?id=12819 --- Comment #3 from Paul Slootman --- How about just using a post-xfer command on the server side that does 'sync'? -- You are receiving this mail because: You are the QA Contact for the bug. -- Please use reply-all for most

[Bug 12819] [PATCH] sync() on receiving side for data consistency

https://bugzilla.samba.org/show_bug.cgi?id=12819 --- Comment #2 from Ben RUBSON --- Thank you for your feedback Brian. I don't have any problem. I just want to be sure that when client (sender) has finished its transfer, its data is on server's (receiver) disks, before it