pyfilesystem icon indicating copy to clipboard operation
pyfilesystem copied to clipboard

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

Open GoogleCodeExporter opened this issue 10 years ago • 7 comments

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

GoogleCodeExporter avatar Apr 11 '15 10:04 GoogleCodeExporter

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

GoogleCodeExporter avatar Apr 11 '15 10:04 GoogleCodeExporter

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

GoogleCodeExporter avatar Apr 11 '15 10:04 GoogleCodeExporter

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

GoogleCodeExporter avatar Apr 11 '15 10:04 GoogleCodeExporter

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

GoogleCodeExporter avatar Apr 11 '15 10:04 GoogleCodeExporter

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

GoogleCodeExporter avatar Apr 11 '15 10:04 GoogleCodeExporter

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

GoogleCodeExporter avatar Apr 11 '15 10:04 GoogleCodeExporter

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

GoogleCodeExporter avatar Apr 11 '15 10:04 GoogleCodeExporter