Using pyfilesystem + tahoe-lafs + docan. TypeError: unsupported operand type(s) for >>: 'NoneType' and 'int'.
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 [email protected] on 5 Dec 2011 at 3:12
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 [email protected] on 5 Dec 2011 at 8:20
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 [email protected] on 8 Dec 2011 at 12:49
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 [email protected] on 18 Dec 2011 at 4:30
Apparently this error was caused by damage to the shell Python. After I
reinstalled it, the error disappeared.
Original comment by [email protected] on 18 Dec 2011 at 6:22
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 [email protected] on 19 Dec 2012 at 10:36
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 [email protected] on 21 Dec 2012 at 1:05
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 [email protected] on 21 Dec 2012 at 1:15