Showing content from http://mail.python.org/pipermail/python-dev/attachments/20060628/0ddeea2e/attachment.html below:
<br><br><div><span class="gmail_quote">On 6/28/06, <b class="gmail_sendername">Jim Jewett</b> <<a href="mailto:jimjjewett@gmail.com">jimjjewett@gmail.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On 6/27/06, Neal Norwitz <<a href="mailto:nnorwitz@gmail.com">nnorwitz@gmail.com</a>> wrote:<br>> On 6/27/06, Brett Cannon <<a href="mailto:brett@python.org">brett@python.org</a>> wrote:<br>> ><br>> > > (5) I think file creation/writing should be capped rather than
<br>> > > binary; it is reasonable to say "You can create a single temp file up<br>> > > to 4K" or "You can create files, but not more than 20Meg total".<br><br>> > That has been suggested before. Anyone else like this idea?
<br><br>> [ What exactly does the limit mean? bytes written? bytes currently stored? bytes stored after exit?]<br><br>IMHO, I would prefer that it limit disk consumption; a deleted or<br>overwritten file would not count against the process, but even a
<br>temporary spike would need to be less than the cap.<br><br>That said, I would consider any of the mentioned implementations an<br>acceptable proxy; the point is just that I might want to let a program<br>save data without letting it have my entire hard disk.
<br><br></blockquote></div><br>Well, that's easy to solve; don't allow any files to be open for writing. =)<br><br>-Brett<br>
RetroSearch is an open source project built by @garambo
| Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4