https://bugzilla.samba.org/show_bug.cgi?id=13317
--- Comment #3 from Dave Gordon <dg32...@zoho.eu> --- (In reply to Rui DeSousa from comment #2) Here's a snippet from Oracle's ZFS help ... https://docs.oracle.com/cd/E19253-01/819-5461/gitfx/index.html "Enforcement of user and group quotas might be delayed by several seconds. This delay means that users might exceed their quota before the system notices that they are over quota and refuses additional writes with the EDQUOT error message." So, rsync(1) might (a) successfully write a bunch of data that falls just short of the quota, (b) "successfully" (i.e. with no reported error) write some more that takes it over quota (c) close the file (ignoring any result) (d) rename the file -- which may or may not work. ZFS probably notices the quota problem somewhere between (b) and (c), drops the excess data, and returns EDQUOT to the close(2) call. The success of the rename depends only on whether there is sufficient free space at that instant; any previous failure in writing the file won't affect the rename directly. Rename may not always need any extra space anyway. BTW: apropos your comment about "cat" in thread https://www.postgresql.org/message-id/E6AB850C-D05E-405B-8D4E-DE18E128F402%40icloud.com it's not the cat that makes this reliable, it's the ssh! :) HTH, .Dave. -- You are receiving this mail because: You are the QA Contact for the bug. -- Please use reply-all for most replies to avoid omitting the mailing list. To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
