RetroSearch Browse

Wed Jun 28 21:02:05 CEST 2006 · https://mail.python.org/pipermail/python-dev/2006-June/066731.html

Guido van Rossum wrote:
> On 6/28/06, Brett Cannon <brett at python.org> wrote:
>> On 6/28/06, Guido van Rossum <guido at python.org> wrote:
>>> - File size should be rounded up to some block size (512 if you don't
>>> have filesystem specific information) before adding to the total.
>> Why?
> 
> Because that's how filesystems work. Allocations are in terms of block
> sizes. 1000 files of 1 byte take up the same space as 1000 files of
> 512 bytes (in most common filesystems anyway -- I think Reiserfs may
> be different).

Forgive me if I'm missing the obvious but shouldn't block size be taken 
into consideration when setting the cap rather than for testing the file 
size? E.g., what happens if you specify a cap of 100 bytes, your block 
size is 512 and the user tries to write a single byte? Fail, because 
it's logically allocation 512 and the cap is at 100? That seems 
backwards to me since it would require that the app first determine the 
block size of the OS it's running on before it can even set a "working" 
cap.

And if the interpreter implicitly rounds the cap up to block size, then 
there isn't much of a point in specifying the number of bytes to begin 
with - perhaps use number of blocks instead?

In any case, I'd argue that if you allow the cap to be set at any 
specific number of bytes, the interpreter should honor *exactly* that 
number of bytes, blocks or not.

Cheers,
   - Andreas

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2006-June/066731.html below:

[Python-Dev] doc for new restricted execution design for Python