Closed GoogleCodeExporter closed 9 years ago
The open flag being passed isn't being converted back to a string. The OS
passes the
flag as an int (as opposed to the 'r', 'w', 'r+', 'rb' etc. that we're familiar
with). I've accounted for all the flags that I've seen appear in Linux so OSX
may be
using different int values (or it could differentiate between 'r' and 'rb').
To get more information, edit gFile.py and insert:
print "Flags = ", flags
in line 260 (above f = flags). Run it again and paste the debug output here.
Basically, this number will be different to the ones already included in the
file and
the solution will be to include a new "elif flags == (number):" line to assign
f to
the appropriate integer to pass into open.
Cheers,
Scott W
Original comment by d38dm8nw81k1ng@gmail.com
on 18 Jan 2010 at 8:53
[deleted comment]
[deleted comment]
with the code below i can now read the files from google docs!
any suggestions on how to enable readwrite on this filesystem?
the code seems to be in gFile.write etc but it seems fuse is presenting readonly
are you aware of other debug options apart from the -d switch to see what fuse
is doing?
regards, hoyte
#
#define O_RDONLY 0x0000 /* open for reading only */
#define O_WRONLY 0x0001 /* open for writing only */
#define O_RDWR 0x0002 /* open for reading and writing */
#define O_ACCMODE 0x0003 /* mask for above modes */
#define O_NONBLOCK 0x0004 /* no delay */
#define O_APPEND 0x0008 /* set append mode */
#
# r read
# w write (overwrite is exists)
# a append (from eof, create if necessary)
# r+ read and write
# w+ read and write as w
# a+ read and write as a
# b binary on non-posix
#
if flags == 32768:
f = 'r'
elif flags == 32769:
f = 'w'
elif flags == 32770:
f = 'r+'
elif flags == 33793:
f = 'a'
elif flags == 33794:
f = 'a+'
elif flags == 0:
f = 'r'
elif flags == 1:
f = 'w'
elif flags == 2:
f = 'r+'
else: # Assume that it was passed from self.read()
f = flags
Original comment by hoyte.sw...@gmail.com
on 19 Jan 2010 at 3:08
Hi,
Sorry about the late reply. I forgot to star the issue so Google didn't think to
email me :-/
I only know about -d. It gives some decent information and you can stick print
statements in the code to work out the value of different variables, as well as
seeing uncaught exceptions.
Is there an equivalent to stat in OSX? Using that, with -d should give some
information on the file that I might be able to interpret if you paste it here.
Scott
Original comment by d38dm8nw81k1ng@gmail.com
on 8 Feb 2010 at 9:42
Hi d38dm8nw81k1ng ;-)
I have added traces of the steps in opening "Document.doc" which gets opened
read-only and a save-as "Document2.doc".
I have tried figuring out why the file is presented in read-only mode but was
not
successful sofar.
It seems to be related to the creation of a lockfile that fails,
probably because the mount does not allow writes?
===== DEBUG ===== : os.mknod(
/Users/hoyte/.google-docs-fs/.~lock.Document.doc# ,0644)
unique: 8, error: -1 (Operation not permitted), outsize: 16
any help appreciated, hoyte
Original comment by hoyte.sw...@gmail.com
on 9 Feb 2010 at 12:26
Attachments:
Ahhh you're using OOo3.1. That explains a lot actually. I've never been able to
work
out why, but OOo3.x doesn't like google-docs-fs very much... well at all
actually.
I tried to work around the lock file problems but OOo kept finding new and ever
more
imaginative ways to screw me over :-(
The guys at OOo came up with lock files as a way of implementing portable file
locking, which any other office suite (such as MS Office) will happily ignore.
To get around it, I tried to have google-docs-fs recognise the lock file and
instead
of trying to upload it, it would redirect OOo to a temporary location on the
file
system to read from. For whatever reason, the lock file was corrupted. After
writing
to the file, it would be reopened and the last character overwritten with the
null
character. Unfortunately my attempts to prevent this were in vain. Currently,
OOo3
still doesn't work properly. OOo2.x works perfectly fine and it's likely MS
Office
will work just as well (though I've never tested it).
Check out Issue #6 for more information on the problem.
Original comment by d38dm8nw81k1ng@gmail.com
on 9 Feb 2010 at 12:37
ah, i read #6 but interpreted it to be fixed. i will start downloading the v2
then...
if however i open the file in the .google-docs-fs cache directory everything
works
correctly. could i not redirect the lockfile handling to this directory to make
oo
happy? a regexp for the lockfiles can detect such files.
also, if i look at the traces, the lockfile handling comes after the opening of
the file.
it is first opened with flags=0 (readonly)
unique: 6, opcode: OPEN (14), nodeid: 5, insize: 48
===== DEBUG ===== : GFile.open():
===== DEBUG ===== : parm1: path: /Document.doc
===== DEBUG ===== : parm2: flags: 0
unique: 6, error: 0 (Unknown error: 0), outsize: 32
OPEN[6441032] flags: 0x0 /Document.doc
then it is opened again with flags=2 (readwrite)
unique: 0, opcode: OPEN (14), nodeid: 5, insize: 48
===== DEBUG ===== : GFile.open():
===== DEBUG ===== : parm1: path: /Document.doc
===== DEBUG ===== : parm2: flags: 2
unique: 0, error: 0 (Unknown error: 0), outsize: 32
OPEN[6689016] flags: 0x2 /Document.doc
then a non-implemented create of the lockfile is tried
unique: 7, opcode: LOOKUP (1), nodeid: 1, insize: 61
LOOKUP /.~lock.Document.doc#
===== DEBUG ===== : GFile.getattr():
===== DEBUG ===== : parm1: path: /.~lock.Document.doc#
unique: 7, error: -2 (No such file or directory), outsize: 16
unique: 4, opcode: CREATE (35), nodeid: 1, insize: 69
unique: 4, error: -78 (Function not implemented), outsize: 16
and then finally a failing mknod
unique: 8, opcode: MKNOD (8), nodeid: 1, insize: 69
MKNOD /.~lock.Document.doc#
===== DEBUG ===== : GFile.mknod():
===== DEBUG ===== : parm1: path: /.~lock.Document.doc#
===== DEBUG ===== : parm2: mode: 33188
===== DEBUG ===== : parm3: dev: 0
===== DEBUG ===== : tmp_path:
/Users/hoyte/.google-docs-fs/.~lock.Document.doc#
===== DEBUG ===== : tmp_dir: /Users/hoyte/.google-docs-fs/
===== DEBUG ===== : filename[0]: .
===== DEBUG ===== : os.makedirs( /Users/hoyte/.google-docs-fs/ ,0644)
===== DEBUG ===== : except OSError
===== DEBUG ===== : os.mknod(
/Users/hoyte/.google-docs-fs/.~lock.Document.doc# ,0644)
unique: 8, error: -1 (Operation not permitted), outsize: 16
is the last step not the problem? because the open readwrite apparently is
succesfull?
regards, hoyte
Original comment by hoyte.sw...@gmail.com
on 9 Feb 2010 at 1:04
I'm not sure how it works in OS X, but under Linux the temporary file was being
created and copied successfully and then overwritten with an invalid file
(triggering
OOo3's locking). I didn't want to put the code into the release as I was simply
risking instability without getting any benefit from it, as it still didn't
seem to work.
Regards,
Scott
Original comment by d38dm8nw81k1ng@gmail.com
on 14 Feb 2010 at 7:48
The OOo3.x errors are now fixed and in the SVN and released under Downloads.
I'm
closing this but if you find you're still having problems, just post and I'll
reopen
it.
Original comment by d38dm8nw81k1ng@gmail.com
on 27 May 2010 at 9:43
Original issue reported on code.google.com by
hoyte.sw...@gmail.com
on 16 Jan 2010 at 5:20