Closed GoogleCodeExporter closed 9 years ago
I can't reproduce this on trunk. It's probably been fixed.
Can you try the latest from svn, and confirm it resolves this issue?
Original comment by willmcgugan
on 5 Sep 2013 at 10:24
I can confirm that the problem is not present in svn, but it appears that the
newest version requires Python 2.7, due to the use of io.SEEK_* constants. I am
currently using 0.4.0 with Python 2.6.
Original comment by clint.he...@gmail.com
on 6 Sep 2013 at 4:10
Ah. I've fixed that. We want to maintain 2.6 compatibility for the foreseeable
future.
Original comment by willmcgugan
on 6 Sep 2013 at 9:41
Regarding the SEEK_* stuff - not that it really matters, but for the sake of
consistency would it have been better to fix it the same way that
http://code.google.com/p/pyfilesystem/source/browse/trunk/fs/remote.py#37 does?
In fact, I just did a:
grep -R SEEK_\\\(SET\\\|CUR\\\|END\\\) fs | grep -v '/.svn/' | grep -v ^Binary
and that shows that the only files _not_ using the fs.SEEK_* constants are
fs/tests/__init__.py
fs/iotools.py
fs/expose/dokan/__init__.py
fs/memoryfs.py
so maybe they should all be modified to use the fs versions? *shrug*
Original comment by gc...@loowis.durge.org
on 7 Sep 2013 at 7:20
Good point. I had forgotten we had those constants defined. I'll change that.
Original comment by willmcgugan
on 8 Sep 2013 at 11:02
Good point. I had forgotten we had those constants defined. I'll change that.
Original comment by willmcgugan
on 8 Sep 2013 at 11:05
I just confirmed with the latest version (r865) that the 'read(0)' still reads
all data when opening the file in binary mode (due, presumably, to the file
object being an fs.iotools.RawWrapper instead of a io.TextIOWrapper).
Original comment by clint.he...@gmail.com
on 9 Sep 2013 at 7:55
Ah. I found the root cause. I've pushed the fix. Thanks for investigating.
Original comment by willmcgugan
on 9 Sep 2013 at 8:24
Original issue reported on code.google.com by
clint.he...@gmail.com
on 5 Sep 2013 at 7:36