This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author gregory.p.smith
Recipients gregory.p.smith, iritkatriel, larry, ned.deily, serhiy.storchaka
Date 2021-10-21.20:42:28
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1634848948.76.0.285546359189.issue31000@roundup.psfhosted.org>
In-reply-to
Content
this is probably somewhat of an edge case.  filesystems are presumably free to have their own concepts of granularity on size limit enforcement.

zfs may become more popular in future ubuntu versions as they're offering it as a supported primary whole system filesystem.  but zfs is also highly configurable so it likely isn't accurate to just say "zfs" caused this.

that test appears to be setting RLIMIT_FSIZE to 1024 and creating a 1024 byte file.  this could be an edge case, either in our understanding (the limit can never be reached or the limit can be exactly reached?) or in the filesystem's interpretation of that.  my understanding is that it is supposed to be inclusive.  RLIMIT_FSIZE 1024 should allow 1024 byte files.

but for such small unrealistic real world values i can easily imagine filesystems being creative...  people tend not to expect these limits to be so strict.

that test could use refactoring to rely less on strict limits.  that isn't what it was aiming to test.
History
Date User Action Args
2021-10-21 20:42:28gregory.p.smithsetrecipients: + gregory.p.smith, larry, ned.deily, serhiy.storchaka, iritkatriel
2021-10-21 20:42:28gregory.p.smithsetmessageid: <1634848948.76.0.285546359189.issue31000@roundup.psfhosted.org>
2021-10-21 20:42:28gregory.p.smithlinkissue31000 messages
2021-10-21 20:42:28gregory.p.smithcreate