GDriveFS icon indicating copy to clipboard operation
GDriveFS copied to clipboard

Fix broken displaceables

Open mickael9 opened this issue 10 years ago • 2 comments

Displaceables seem to be broken, and also seem to have been that way for some time

The first problem was introduced recently in commit daa1c3844d711c1331872896e9a531bf546af7e2 (using r'' syntax turns \\ into two backslashes instead of just one)

The second one seems to be present for a long time (probably d6b20b77d3b5652e95516fbc99d2eb60786101e7) and is caused by assigning a NamedTemporaryFile file object where a file name was expected. Also, the created temporary file seemed to be removed before I even had a chance to read it

With that being said, I don't really like the concept of displaceables as it requires the user to manually put the complete mime-type and navigate to the corresponding temporary file.

I think a better solution to this would be to expose virtual files with the correct extension for the corresponding exportable mime-types.

For instance, if we have a Google Docs document named "Hello World", we could simply provide the different exportable formats as multiple file entries :

Hello World.pdf
Hello World.docx
Hello World.rtf

The list of allowable extensions that appear in the listing by default would be configurable (not everyone needs .rtf !) and it would still be possible to ask for a specific extension even if it's unlisted.

I have not researched the possible performance issues with this idea, I suppose this could slow down directory listings if fetching each of the exported versions is required in order to expose the correct file size. Perhaps this could be dealt with by using some workaround (by exposing the files as symlinks for instance).

mickael9 avatar Nov 30 '15 21:11 mickael9

I think a better solution to this would be to expose virtual files with the correct extension for the corresponding exportable mime-types.

For instance, if we have a Google Docs document named "Hello World", we could simply provide the different exportable formats as multiple file entries [...]

Would stat() on those virtual files require an export? If so, that could lead to a large performance penalty under the vast majority of use-cases.

PythonNut avatar May 05 '16 03:05 PythonNut

@mickael This PR got by me. @PythonNut's comment brought it to my awareness. Sorry for my inattentiveness.

Yes, displaceables have only been partially conceived since the beginning due to the consequences of how Google makes us deal with these. I don't like how we have to deal with it.

Technically, we can get a list of all members of the directory in order to know what's available. It seems like there might've been a gotcha here, in that we might've only received none or some of the URLs unless we asked for more information for a particular member. No mater what, we won't have the size (the core problem).

As for displaying extensions, I think this would create ambiguity between which have real extensions and which have these "tag" extensions. Plus, not only would it produce a list that is quite a bit longer but we'd also only show extensions which we were familiar with. I don't like the possibly of omitting a potentially useful extension because it's not very common or well-know to GDFS or potentially always displaying an extension that is useless to someone (TXT for people that always use PDF, PDF for people that always use DOC, etc..). It seems like there's an oppressive negative to displaying these by default.

On the other hand, I very much like the idea of doing a prefix match of the file that was entered (essentially what we already do) to determine if an extension was added on to the end (which wouldn't be affected by whether an extension already existed, though we might take an existing one into account). We might have to deal with the corner case of an extension existing that doesn't agree with Google's mimetype or the available types that can be downloaded, but a file-extension is so much more nice than a a hash-prefixed mime-type.

Maybe we could compromise and use a colon followed by a file-extension that represents a downloadable mime-type (which we couldn't validate until dereferencing to a mime-type and indexing a URL). It would make file typing and naming issues coming down from Google a lot less visually confusing.

Feel free to further expand on this. I'm tired and distracted but I'd love to blow this problem out an airlock (with extreme prejudice).

dsoprea avatar May 05 '16 04:05 dsoprea