Bug in redirection uri.

[stefbon]

Hi,

I'm trying fuse-google-drive, and following the steps.

I get an webadress on the commandline, and when opening this in my browser, it shows:

The redirect URI in the request: urn:ietf:wg:oauth:2.0:oob did not match a registered redirect URI

Any idea?

Stef

[jcline]

Did you create the clientsecrets and clientid with Google and place them in ~/.config/fuse-google-drive/clientsecrets and ~/.config/fuse-google-drive/clientid, respectively?

If not, go to http://code.google.com/apis/console then create a new project. A list of Google APIs will be displayed, turn on the Google Drive one. Then, select API Access in the navigation menu on the left. Click the large, blue, "Create an OAuth 2.0 client ID..." and follow the instructions for an "Installed Application." Once completed, they will give you the clientid and clientsecrets tokens.

[stefbon]

Hi,

I've done that already. I've enabled the google drive. Now I've got a screen with API Access, Branding Information, Service account and Simple API Access. I do not see anything about "Create an OAuth...".

Stef

[jcline]

I do not see anything about "Create an OAuth...".

Hmm. On the API Access page, you should have a section called, "Client ID for installed applications" which has the clientid and clientsecrets tokens. It should also have a section that looks like:

Redirect URIs:  urn:ietf:wg:oauth:2.0:oob
                        http://localhost

[stefbon]

I do not have that: Client ID for installed apps.

Well I can remember that when I started enabling Drive, a selection was presented to choose (three options). I chose the second, maybe I had to take the third...

I have a cl;ientid and a private key, it looks like something ssh.

fuse-google-drive is a app/service, not something like a browser. Maybe that caused the confusion.

I'll remove it and try again.

Thanks,

Stef

2012/5/11 jcline reply@reply.github.com:

 I do not see anything about "Create an OAuth...".

Hmm. On the API Access page, you should have a section called, "Client ID for installed applications" which has the clientid and clientsecrets tokens. It should also have a section that looks like:

Redirect URIs:  urn:ietf:wg:oauth:2.0:oob
                       http://localhost

---

Reply to this email directly or view it on GitHub: https://github.com/jcline/fuse-google-drive/issues/28#issuecomment-5650854

[stefbon]

Well I've got a Client ID and clientsecret now. I had to push on the button "Create another client ID", and now I see the section you've mentioned. Sorry, every now and then I do not quite follow/understand computers.

Stef

[jcline]

No problem. If you had trouble with it I'm sure others have and will, so I should put up some clearer instructions. Maybe a video tutorial would help, as well.

[stefbon]

HI,

it's working now, and responsive!!

Great! Earlier I've tried google-docs-fs, which was not responsive. Not everything works, but I know that's already known. (filesizes are zero...)

I've worked on several other fuse fs's myself, and working on a notifyfs ( a filesystem change monitor service), which is aimed to work with networkfilesystems like cifs, nfs and fuse fs's. Maybe I can make this work also with your fs, which would be a very nice and good thing.

Stef

2012/5/11 Stef Bon stefbon@gmail.com:

Well I've got a Client ID and clientsecret now. I had to push on the button "Create another client ID", and now I see the section you've mentioned. Sorry, every now and then I do not quite follow/understand computers.

Stef

[jcline]

Keep in mind that, at the moment, it only returns a cached version of a file after loading it initially. So if you make a change to a file (or someone else does), you will not see it. It also will stop working after 3600 seconds because I do not get a new access token when the initial one expires.

Maybe I can make this work also with your fs, which would be a very nice and good thing.

You should make a new issue listing what I would need to do to support that (is a working stat() all that is needed, etc).

[stefbon]

2012/5/11 jcline reply@reply.github.com:

Keep in mind that, at the moment, it only returns a cached version of a file after loading it initially. So if you make a change to a file (or someone else does), you will not see it. It also will stop working after 3600 seconds because I do not get a new access token when the initial one expires.

You mean that it's not synced with the "original documents" on the internet, and do not see any change there, for example in the view of the browser?

And it's only "visible" again when the fuse fs terminates??

And when someone, for example you, via the browser, changes the "original" file, there might be collision ahead, sinec then there are two different versions...Is there a way to deal with?

Maybe I can make this work also with your fs, which would be a very nice and good thing.

You should make a new issue listing what I would need to do to support that (is a working stat() all that is needed, etc).

No, a lot more... I've worked on a simple fuse overlay fs, and it needed : a. a connection to the notifyfs socket, to receive the "forwarded watch" b. a method to monitor the backend, I do not know there is one with Google Docs. Ive read that it's possible to read the changes via a feed, but it's not pushed to the client by the server, the client has to take care of "polling" that as far as I understand. c. a filter on the fsevent messages from the server to test they represent a real change (not every change send by the server is relevant..) d. send the fsevent back to notifyfs.

Maybe I;m a bit too enthousiast here, your fs is in the "just started" phase, and this does not have too much priority compared to other things.

Stef

[jcline]

You mean that it's not synced with the "original documents" on the internet, and do not see any change there, for example in the view of the browser? And it's only "visible" again when the fuse fs terminates?? And when someone, for example you, via the browser, changes the "original" file, there might be collision ahead, sinec then there are two different versions...Is there a way to deal with?

When you load a file through f-g-d, it loads it from the server, but then does not reload it on future requests, returning the cached version instead. The way I plan on dealing with this issue is to check if the file has been modified before returning the cached version, if it has then it will load the new version. I just have not yet implemented this.

That does sound more complex than I initially thought. It is does sound like a useful idea, though. Once I have the update check working, it should be possible to just spin off a thread which polled periodically and communicated with notifyfs as you described. I will likely do something similar anyway at some point, which that could be tied into.

[stefbon]

2012/5/11 jcline reply@reply.github.com:

You mean that it's not synced with the "original documents" on the internet, and do not see any change there, for example in the view of the browser? And it's only "visible" again when the fuse fs terminates?? And when someone, for example you, via the browser, changes the "original" file, there might be collision ahead, sinec then there are two different versions...Is there a way to deal with?

When you load a file through f-g-d, it loads it from the server, but then does not reload it on future requests, returning the cached version instead. The way I plan on dealing with this issue is to check if the file has been modified before returning the cached version, if it has then it will load the new version. I just have not yet implemented this.

Does it load the whole file, or just a part?? Opening a file via fuse goes via an offset and size, so always a part. When files get bigger, loading the whole file might be a problem.

And isn't there some locking method with google api, to prevent collisions?

That does sound more complex than I initially thought. It is does sound like a useful idea, though. Once I have the update check working, it should be possible to just spin off a thread which polled periodically and communicated with notifyfs as you described. I will likely do something similar anyway at some point, which that could be tied into.

Yes, such a thread can keep your fs uptodate, and send changes to notifyfs.

Stef

[jcline]

Does it load the whole file, or just a part?? Opening a file via fuse goes via an offset and size, so always a part. When files get bigger, loading the whole file might be a problem.

It loads the entire file the first time read() is called for an uncached file. It is "good enough" caching for the moment, despite obvious drawbacks. I haven't decided on a better caching strategy for future use to not waste too much memory without being unreasonably slow.

And isn't there some locking method with google api, to prevent collisions?

Now that I don't know, but if there is it would be rather useful.

[jcline]

Thought I would let you know that I recently added support for getting some file updates. The things that don't work still are newly created files, renamed files, and deleted files.

There are likely issues, but it should do mostly OK.