documents do show up in .google-docs-fs but not in mounted directory

[GoogleCodeExporter]

1. python -m trace --trace
/Library/Python/2.5/site-packages/google-docs-fs/gFile.py
/Users/myid/Documents/gdocs myid@gmail.com -d
2. strings /Users/myid/Documents/gdocs/Samples/Document.doc
3. strings /Users/myid/.google-docs-fs/Samples/Document.doc

the file is present in the .google-docs-fs directory and can be read correctly
but the file in the gdocs/Samples directory is shown in finder and with ls
but can not be opened

Mac OS X 10.5.8
MacFUSE 2.0.3
fuse-python-0.2
gdata-2.0.6
google-docs-fs-1.0beta4

i have added some debug statements in the code for tracing...

unique: 3, opcode: GETATTR (3), nodeid: 1, insize: 40
===== DEBUG ===== : GFile()/getattr():
   unique: 3, error: 0 (Unknown error: 0), outsize: 128
unique: 4, opcode: LOOKUP (1), nodeid: 1, insize: 48
LOOKUP /Samples
===== DEBUG ===== : GFile()/getattr():
===== DEBUG ===== : GFile()/_setattr():
===== DEBUG ===== : GFile()/_time_convert():
===== DEBUG ===== : GFile()/_time_convert():
===== DEBUG ===== : GFile()/_time_convert():
   NODEID: 2
   unique: 4, error: 0 (Unknown error: 0), outsize: 152
unique: 0, opcode: LOOKUP (1), nodeid: 2, insize: 53
LOOKUP /Samples/Document.doc
===== DEBUG ===== : GFile()/getattr():
===== DEBUG ===== : GFile()/_setattr():
===== DEBUG ===== : GFile()/_time_convert():
===== DEBUG ===== : GFile()/_time_convert():
===== DEBUG ===== : GFile()/_time_convert():
   NODEID: 3
   unique: 0, error: 0 (Unknown error: 0), outsize: 152
unique: 1, opcode: OPEN (14), nodeid: 3, insize: 48
===== DEBUG ===== : GFile()/open():
===== DEBUG ===== : open(): parm1: path: /Samples/Document.doc
===== DEBUG ===== : open(): parm2: flags: 0
DEBUG: get_file(): parm1: path: /Samples/Document.doc
DEBUG: get_file(): parm2: tmp_path:
/Users/hoyte/.google-docs-fs/Samples/Document.doc
DEBUG: get_file(): parm3: flags: 0
/Library/Python/2.5/site-packages/google-docs-fs/gNet.py:202:
DeprecationWarning: Please use Export instead
  self.gd_client.DownloadDocument(file.resourceId.text,
tmp_path.encode(self.codec))
Traceback (most recent call last):
  File "build/bdist.macosx-10.5-i386/egg/fuse.py", line 361, in __call__
  File "build/bdist.macosx-10.5-i386/egg/fuse.py", line 775, in wrap
  File "/Library/Python/2.5/site-packages/google-docs-fs/gFile.py", line
280, in open
    file = self.gn.get_file(path, tmp_path, f)
  File "/Library/Python/2.5/site-packages/google-docs-fs/gNet.py", line
204, in get_file
    return open(tmp_path.encode(self.codec), flags)
TypeError: file() argument 2 must be string, not int
   unique: 1, error: -22 (Invalid argument), outsize: 16

any help appreciated
regards, hoyte

Original issue reported on code.google.com by hoyte.sw...@gmail.com on 16 Jan 2010 at 5:20

[GoogleCodeExporter]

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

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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:

• gdocs1_login.txt
• gdocs2_open_topdir_with_finder.txt
• gdocs3_open_document.txt
• gdocs4_saveas_document2.txt
• gdocs4_saveas_document2.jpg
• gdocs5_close_document.txt
• gdocs6_df_mount.txt

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

• Changed state: Accepted

[GoogleCodeExporter]

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

• Changed state: Fixed