search

piranna / pyfilesystem

Automatically exported from code.google.com/p/pyfilesystem
BSD 3-Clause "New" or "Revised" License
1 stars 0 forks source link

Using pyfilesystem + tahoe-lafs + docan. TypeError: unsupported operand type(s) for >>: 'NoneType' and 'int'. #96

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. Go to any catalog with files.
2. See log.

What version of the product are you using? On what operating system?
All latest.
tahoe-lafs 1.9.0 + pyfilesystem 0.4 (and svn r723) + dokan 0.6.0
OS Windows 7 x64 Russian + Python 2.7.2 x86

Traceback (most recent call last):
  File "_ctypes/callbacks.c", line 313, in 'calling callback function'
  File "C:\Program Files (x86)\Python27\lib\site-packages\fs\expose\dokan\__init__.py", line 256, in wrapper
    return func(self,*args)
  File "C:\Program Files (x86)\Python27\lib\site-packages\fs\expose\dokan\__init__.py", line 173, in wrapper
    res = func(*args,**kwds)
  File "C:\Program Files (x86)\Python27\lib\site-packages\fs\errors.py", line 191, in wrapper
    return func(*args,**kwds)
  File "C:\Program Files (x86)\Python27\lib\site-packages\fs\expose\dokan\__init__.py", line 604, in FindFilesWithPattern
    data = self._info2finddataw(fpath,finfo,None)
  File "C:\Program Files (x86)\Python27\lib\site-packages\fs\expose\dokan\__init__.py", line 794, in _info2finddataw
    data.nFileSizeHigh = info.get("size",0) >> 32
TypeError: unsupported operand type(s) for >>: 'NoneType' and 'int'

Original issue reported on code.google.com by int...@gmail.com on 5 Dec 2011 at 3:12

GoogleCodeExporter commented 9 years ago 
If you could also report this on the Tahoe-LAFS trac that would help us 
Tahoe-LAFS hackers:

https://tahoe-lafs.org

Original comment by zoo...@gmail.com on 5 Dec 2011 at 8:20

GoogleCodeExporter commented 9 years ago 
I opened an issue ticket in the Tahoe-LAFS project to track this issue: 
https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1634

Original comment by zoo...@gmail.com on 8 Dec 2011 at 12:49

GoogleCodeExporter commented 9 years ago 
I wrote the following over on the Tahoe-LAFS issue tracker: As far as I know, 
pyfilesystem doesn't have a strong test suite, so it will require more effort 
from someone to figure out where exactly the problem lies in pyfilesystem, 
Tahoe-LAFS, dokan, or the interfaces between them...

Original comment by zoo...@gmail.com on 18 Dec 2011 at 4:30

GoogleCodeExporter commented 9 years ago 
Apparently this error was caused by damage to the shell Python. After I 
reinstalled it, the error disappeared.

Original comment by int...@gmail.com on 18 Dec 2011 at 6:22

GoogleCodeExporter commented 9 years ago 
I'm thinking this is related to my same issue.  I have a Tahoe-LAFS mounted 
through PyFS on Linux and I was using the same one earlier on Windows with 
docan.  I saw similar things on docan, but didn't write them down.  I mount the 
directory and do an 'ls'.  This is the error I'm seeing on Linux:
Traceback (most recent call last):
  File "/usr/local/lib/python2.7/dist-packages/fs/expose/fuse/fuse_ctypes.py", line 294, in _wrapper_
    return func(*args, **kwargs) or 0
  File "/usr/local/lib/python2.7/dist-packages/fs/expose/fuse/fuse_ctypes.py", line 425, in readdir
    set_st_attrs(st, attrs)
  File "/usr/local/lib/python2.7/dist-packages/fs/expose/fuse/fuse_ctypes.py", line 239, in set_st_attrs
    setattr(st, key, val)
TypeError: an integer is required

This is due to me having some MDMF files in the directory.  When I unlink them 
from the directory, I get immediate results from my 'ls'.  I think the problem 
is that MDMF files don't have a "size" always.  In the JSON for the DIR:CAP, I 
have the file size listed as:
"size": null
When I run a "check/renew/verify every bit" on the MDMF, it spits out the size 
for a while and then the 'ls' works for a time.

The change to fix this should either be in TahoeLAFS to output something like 0 
for a null sized file, or at least an integer, like "-1", or the code here 
should be updated to check "size" for null and replace it with 0 or a "-1".

Original comment by rand...@mason.ch on 19 Dec 2012 at 10:36

GoogleCodeExporter commented 9 years ago 
I suspect it's more likely that we'll change the JSON output to omit the 
{{{"size"}}}, at which point the pyFilesystem Tahoe-LAFS backend should work 
(reporting a zero file size) because it uses {{{info.get("size",0)}}}.

Original comment by davidsar...@googlemail.com on 21 Dec 2012 at 1:05

GoogleCodeExporter commented 9 years ago 
Actually, if the "size" field is missing then it gets coerced to 0 here: 
http://code.google.com/p/pyfilesystem/source/browse/trunk/fs/contrib/tahoelafs/u
til.py#79

Original comment by davidsar...@googlemail.com on 21 Dec 2012 at 1:15