[tahoe-dev] [tahoe-lafs] #637: support "keep this much disk space free" on Windows as well as other platforms

[tahoe-lafs]

#637: support "keep this much disk space free" on Windows as well as other
platforms
-------------------------------+--------------------------------------------
 Reporter:  zooko              |           Owner:  kevan   
     Type:  defect             |          Status:  assigned
 Priority:  major              |       Milestone:  1.6.0   
Component:  code-storage       |         Version:  1.3.0   
 Keywords:  win32 easy review  |   Launchpad_bug:          
-------------------------------+--------------------------------------------

Comment(by kevan):

 The tests work okay on my Mac.

 I'm not sure how closely we adhere to PEP-8 (the
 [http://allmydata.org/trac/tahoe/wiki/CodingStandards CodingStandards]
 page mentions it, but lots of code in tahoe-lafs ignores it), but a number
 of places in the patch violate it. In particular,

   * The stuff in _auto_deps.py
   * Line 45 of src/allmydata/storage/server.py
   * The docstring starting on line 160 of src/allmydata/storage/server.py.
   * The docstring starting on line 243 of src/allmydata/storage/server.py.

 On lines 42 and 46 of src/allmydata/storage/server.py, you have Windows
 line endings instead of unix line endings. I'm not sure how big a deal
 this is, but most of the other code seems to use unix line endings.

 I don't understand why we treat a failure in the win32api system call the
 same way as not having an API to determine disk usage. In the former case,
 we make the server read-only and report that it has no free space. In the
 latter case, we make the server writable and report that it has an
 arbitrary amount of free space. To me, these errors seem like two
 different expressions of the same problem -- that the server can't figure
 out how much free space there is. Why not treat them the same?

 Or, put another way: If the user specifies a reserved space requirement,
 and we can't honor it (for whatever reason), we should make the server
 read only (or at least that seems more right to me).

 (this isn't so much a critique of the patch -- indeed, this is existing
 behavior -- as a question that the patch makes me want to ask. Perhaps I
 should open another ticket for it?)

 In any case, expressions of this issue are on lines 225 and 249 of
 src/allmydata/storage/server.py.

 I like the tests -- I don't see any problems with them.

-- 
Ticket URL: <http://allmydata.org/trac/tahoe/ticket/637#comment:23>
tahoe-lafs <http://allmydata.org>
secure decentralized file storage grid