[tahoe-lafs-trac-stream] [Tahoe-LAFS] #1634: TypeError due to "size" being None in pyfilesystem+dokan

[Tahoe-LAFS]

#1634: TypeError due to "size" being None in pyfilesystem+dokan
-------------------------+-------------------------------------------------
     Reporter:  zooko    |      Owner:  Zancas
         Type:  defect   |     Status:  new
     Priority:  major    |  Milestone:  1.11.0
    Component:  code-    |    Version:  1.9.0
  frontend-web           |   Keywords:  pyfilesystem dokan error webapi
   Resolution:           |  docs mutable test-needed
Launchpad Bug:           |
-------------------------+-------------------------------------------------

Comment (by warner):

 I'm late to the party, but in my opinion:

 * It'd be wrong to claim size=0 when in fact we don't know. We need a
 different indicator
 * For a python interface, I'd return None to mean "we don't know". The two
 basic options are to have `data["size"] = None` or to omit `data["size"]`
 entirely. I like consistency. Both options require the client to be
 prepared to deal with an unknown-size, either with something like `print
 'size: %s' % (data['size'] or 'unknown')` or `print 'size: %s' %
 data.get('size', 'unknown')`. I guess I'm slightly in favor of having the
 set of keys be constant, and put the variability in the values.
 * For JSON, I think it's reasonable to return `null`
 * But I'm -0 on omitting the field: I won't oppose it if that's what
 someone else prefers.
 * If a frontend like pyfilesystem is coercing null or a missing key into
 some other value like "0", that's their business. We shouldn't be lying to
 them about the size of the file, but they're welcome to lie to themselves
 or their own users.

--
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1634#comment:11>
Tahoe-LAFS <https://Tahoe-LAFS.org>
secure decentralized storage