summaryrefslogtreecommitdiff
path: root/daemon/gvfsbackendgoogle.c
Commit message (Collapse)AuthorAgeFilesLines
* google: Add Shared drives folderOndrej Holy2021-02-121-13/+146
| | | | | | | | Currently, it is not possible to browse files available over Shared drives (formerly Team drives). Let's add Shared drives folder to the root to make them available. Fixes: https://gitlab.gnome.org/GNOME/gvfs/-/issues/377
* google: Set G_FILE_ATTRIBUTE_ACCESS_CAN_WRITE and _READ attributesOndrej Holy2021-02-121-0/+4
| | | | | | The G_FILE_ATTRIBUTE_ACCESS_CAN_WRITE and G_FILE_ATTRIBUTE_ACCESS_CAN_READ attributes are not set currently. Let's use the newly added libgdata API to set them.
* google: Provide volatile entries for old URIsOndrej Holy2021-02-121-2/+20
| | | | | | The My Drive folder was added to the root, which changed URIs from /file-id to /root-id/file-id. Let's provide volatile entries in the old locations to not break user bookmarks...
* google: Add Shared with me folderOndrej Holy2021-02-121-32/+191
| | | | | | | | Currently, it is not possible to browse files which are shared with the user (the Shared with me folder on the web). Let's add My Drive and Shared with me folder to the root to make them available. Fixes: https://gitlab.gnome.org/GNOME/gvfs/-/issues/444
* google: Increase number of results in batches for better performanceOndrej Holy2021-02-121-3/+1
| | | | | | | | | Currently, only 50 results are returned in one batch, which means that multiple network requests are needed for folders with a lot files, which makes it slow. I am not sure there was some reason for this limitation earlier (e.g. before the cache rework), however, I don't see any rationals for it currently. Let's increase this to its maximum for better performance.
* daemon: Set filesystem::use-preview explicitlyAntónio Fernandes2021-01-221-0/+1
| | | | | | | It can be correctly implied from the value of filesystem::remote for many backends, but let's make it explicit for them too. Fixes https://gitlab.gnome.org/GNOME/gvfs/-/issues/497
* google: Report progress for file transfers from local filesystemOndrej Holy2020-12-011-9/+11
| | | | | | | | | Google backend doesn't report progress from push job. As a consequence, Nautilus shows wierd time estimations when moving/copying file from local filesystem. Let's add custom splice function and report progress from it. Fixes: https://gitlab.gnome.org/GNOME/gvfs/-/issues/463
* google: Set the display name for the root folder alsowip/oholy/google-display-nameOndrej Holy2020-10-211-5/+11
| | | | | | | | | As per the documentation, it is guaranteed that the display name attribute is always set. The same applies for the name attribute. However, this is not true for the root of the google backend. This sometimes causes file chooser crashes currently. Let's set those attributes also for root. Fixes: https://gitlab.gnome.org/GNOME/gvfs/-/issues/523
* trash: Do not fail when G_FILE_COPY_NO_FALLBACK_FOR_MOVE is usedwip/oholy/trash-performanceOndrej Holy2020-09-241-0/+6
| | | | | | | | | | | | | | Restoring files from the trash folder is slow in Nautilus as it attempts to do it recursively. This is because G_IO_ERROR_NOT_SUPPORTED is returned from g_file_move when G_FILE_COPY_NO_FALLBACK_FOR_MOVE flag is used. The error is returned from client-side for pull/push operations after commit 2e765449 as in the most cases the copy-and-delete approach is really used there. But the problem is that it is not in all cases, like in the trash backend case, where the native move operation is used in fact. Let's handle the G_FILE_COPY_NO_FALLBACK_FOR_MOVE flag directly in the backends, but not in the trash backend. Fixes: https://gitlab.gnome.org/GNOME/nautilus/-/issues/1589
* google: Changed copy, move and push to enable overwriting filesMayank Sharma2020-01-311-110/+487
| | | | | | | | | | | | | | | | | | | | Until this commit, copy and move operations weren't capable of performing an actual overwrite of file contents and used to report an error (G_IO_ERROR_NOT_SUPPORTED). This commit adds the functionality to perform an overwrite operation if there exists another file with the same title in the destination directory. This behaviour is desired because it conforms to how normal copy/move operations happen in normal POSIX world. Since, multiple files with same title can exist in destination folder, the copy/move operation now explicity checks and only allows the overwrite operation in case there exists a single file with same title as the source file, otherwise it performs a blind copy/move. (Blind copy here means that a completely new file gets created with same title as source in case of copy, whereas for move the source file simply gets moved). The push function has been modified as well to behave similar to copy/move.
* google: Fixed a bug in copy function which caused crash after renameMayank Sharma2020-01-311-18/+41
| | | | | | | | | | | | | Copy function had the classic time-of-check-to-time-of-use (TOCTOU) bug with the source_entry, which resulted into backend crash due to an entry getting invalidated between two uses. More precisely, we used to check for `existing_entry` using `resolve_child()` which internally calls `rebuild_dir()`. At the beginning of function, we resolve `source_entry`, but if resolve_child rebuilds the directory, our initial reference to source_entry will get freed, resulting into a crash. This commit refactors some of the copy function's code to fix this issue.
* build: Bump libgdata dependency to support latest featuresMayank Sharma2020-01-311-16/+0
| | | | | | | | | libgdata API has been augmented with GDataDocumentsProperty API in the latest release 0.17.11. Since, we're using that API to support copy/move operations, we bump the required dependency version accordingly. We also remove the HAVE_LIBGDATA_* ifdefs since we require libgdata version >= 0.17.11 for the google backend to work properly.
* google: Fix make_directory to create folders with volatile entriesMayank Sharma2020-01-311-1/+43
| | | | | | | | | | | While copying a folder recursively, nautilus calls make_directory operation with the ID of the folder (instead of the title). Although this successfully copies the folder (and its contents too), the titles of all the folders (nested within) are lost. We fix this behaviour of make_directory by checking if the basename is some other folder's ID, and conditionally inserting Source_ID_Property and Parent_ID_Property on the new folder (to create a volatile entry).
* google: Added vfunc for move operationMayank Sharma2020-01-311-0/+234
| | | | | | | | | | | | | | | Earlier, google-drive backend relied on copy/delete fallback to perform the move operation. This operation would atleast require 2 HTTP requests to the Drive API and in the cases of trying to move directories, it won't even succeed (non-empty directory deletion is disabled). We now add vfunc for proper move operation which can move files/directories in a single HTTP request. Since, update operation on file/directory supports writing to the "parents" array, this operation uses `gdata_service_update_entry ()` to update the parents of file/directory to be moved. Fixes: https://gitlab.gnome.org/GNOME/gvfs/issues/8
* google: Improved debug info being logged while insert/delete/queryMayank Sharma2020-01-311-2/+5
| | | | | | | | | | query_info operation is the most called operation, and generally gives a good idea about the state of cache before and after any other operation. We now log the whole cache while doing query_info operation. Also, some other debug information in `insert_entry_full` and `remove_entry_full` has also been improved, i.e. it now logs conditionally while inserting/removing any entry.
* google: Added "GVFS_GOOGLE_DEBUG" env var to log all the entries in cacheMayank Sharma2020-01-311-0/+35
| | | | | | To better check the state of cache before and after a copy operation is performed, we have added a function which checks for "DEBUG_CACHE" environment variable (any value) and logs all the entries to console.
* google: Fix in-fs copy operation using stored volatile pathsMayank Sharma2020-01-311-46/+367
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Owing to the loss of filename, the copy operation was disabled a long time ago in (https://bugzilla.gnome.org/show_bug.cgi?id=755701). Normally, for POSIX based systems, copying `/file1` to directory `/folder1` is done by doing copy ('/file1', '/folder1/file1'). Since, google drive backend uses IDs as filenames (which are not human readable), so doing a copy operation normally should constitute of doing `copy ('/id1', '/folder1/id2')`, but instead GIO being POSIX compliant does `copy ('/id1', '/folder/id1')`. Furthermore, after the copy operation has been done, nautilus performs a `query_info` operation on the path `/folder1/id1` (to check if the file has actually been copied) but since the newly created file inside `/folder1` has the new path `/folder1/id2` (where 'id2' is generated by Drive API) this operation fails resulting in an error and the new file's title being set to `id1` (Loss of titles). To counter this issue, we store `id1` in Properties Resource on the new file being created, and insert a "fake" entry into the cache. This fake entry (`('id1', 'parent') -> GDataEntry`) gives the illusion that the file exists after the copy operation, and hence the `query_info` operation doesn't fail, and copies the file (while retaining title) successfully. This commit enables copy operation and handles most of the quirky cases of Drive, e.g. files having same title in a directory, file being copied over to same folder, etc. Depends upon: https://gitlab.gnome.org/GNOME/libgdata/merge_requests/7 Fixes: https://gitlab.gnome.org/GNOME/gvfs/issues/8
* google: Disable deletion of non-empty directoriesMayank Sharma2019-07-241-0/+35
| | | | | | | | | | | Earlier, we were deleting a directory irrespective of whether it was empty or not. This would cause a permanent deletion of the folder on Drive, and accidental deletions could be catastrophic. `g_file_delete()` states that if a directory is supposed to be deleted, the job should only carry forward to completion if the directory is empty, else it should error out. We fix this behaviour of delete operation in google backend by conforming to GIO's documentation.
* google: Fix crashes when deleting if the file isn't foundMayank Sharma2019-07-241-1/+2
| | | | | | | | | | Currently in delete operation, if the entry gets resolved but parent resolution fails, the jump to `out` label (while handling error) will cause the existing entry's ref_count to decrease by 1 (since `out` label calls g_object_unref on entry). We fix the issue by removing g_object_unref from `out` label and suitably unreffing the entry.
* google: Fix issue with stale entries remaining after rename operationMayank Sharma2019-07-181-1/+7
| | | | | | | | | | | Currently, whenever we perform a rename operation, we set the `entry`'s title to new display name, but at the time of removal of this entry from cache, we still use the newer title. Hence, each time rename is done, a single stale entry remains. This commit fixes the issue by reverting back the title to the original display name of `entry` and then performing a removal from cache. Fixes: https://gitlab.gnome.org/GNOME/gvfs/issues/410
* google: Do not enumerate volatile entries if title matches idOndrej Holy2019-07-151-4/+19
| | | | | | Currently, the volatile entry is enumerated if its title matches id of another entry. But we don't want to enumerate volatile entries to not confuse our clients. Let's add simple check to prevent this.
* google: Check ownership in is_owner() without additional HTTP requestMayank Sharma2019-07-091-46/+14
| | | | | | | | | | | | Earlier, we were fetching ACL feed of an entry and then checking the ownership by comparing account identity with elements from this feed. This was slow due to Network IO being performed while checking ownership. We now use GDataAuthors on a GDataEntry to get the list of "owners" of the file. We then use the GoaObject stored on GDataGoaAuthorizer to get the account which is being used by GDataService. Finally, we take the email address of account and compare them to check the ownership. This method now runs without anymore additional network requests.
* google: Support deleting shared Google Drive filesMayank Sharma2019-05-091-5/+75
| | | | | | | | | | | | | | | | `g_file_delete ()` currently fails for shared files with "Permission denied" error (if they have a different owner and only one parent folder). This is because `gdata_service_delete_entry ()` can't be used for files, which have a different owner. `gdata_documents_service_remove_entry_from_folder ()` has to be used instead in this case (as well as for cases when the files have multiple parents). This fix depends on https://gitlab.gnome.org/GNOME/libgdata/merge_requests/5, which fixes `gdata_documents_service_remove_entry_from_folder ()` implementation to make it work for files with only one parent. Fixes: https://gitlab.gnome.org/GNOME/gvfs/issues/265
* daemon: Use "Operation not supported" consistentlyMayank Sharma2019-03-211-11/+11
| | | | | | | | | GVfs uses different forms of "Operation not supported" string, e.g. "Operation unsupported", "Operation not supported by backend". Let's use "Operation not supported" consistently as this is also used in GLib. https://gitlab.gnome.org/GNOME/gvfs/issues/170
* google: Handle child of volatile also as volatileOndrej Holy2018-09-211-39/+19
| | | | | | Files in volatile folder should be also marked as volatile. Volatile handling is a bit simplified as a part of this patch also.
* google: Use cache for enumeration alsoOndrej Holy2018-09-211-16/+46
| | | | | | | The reworked cache hasn't been used for enumeration results and also for missing files checks, which always caused rebuilding cache. Let's save timestamps also for enumerations and use it to prevent redundant cache rebuilds.
* google: Rework cache for better performanceOndrej Holy2018-09-211-238/+166
| | | | | | | | | | | The backend is totally unusable if you have too many files on your Drive. This happens because the backend preloads the whole Drive's metadata. Let's build the cache incrementaly per folders. As a result, the backend works smoothly regardless of the total number of Drive files, because the total number of transmitted data is significantly reduced. On the other hand, more requests is done to Drive, but the Drive quotas seem big enough.
* google: Remove file just from concrete parentOndrej Holy2018-09-211-4/+33
| | | | | | Files with multiple parents are currently removed from all parents. This is unexpected and may cause data loss, because it is not obvious that it is one file. Let's remove the file just from requested folder.
* google: Add support for files with multiple parentsOndrej Holy2018-09-211-220/+168
| | | | | | | | | One entry can have multiple parents. You can create such entry on the web in a pretty simple way, e.g. Ctrl + Drag&Drop. Such entries are currently shown only on one place in the backend. Also the backend rely on get_parent_id() and get_entry_path() functions which are tottaly wrong. Let's introduce get_parent_ids() and resolve entry_path only from given filename.
* google: Ignore entries without parentsOndrej Holy2018-09-211-17/+1
| | | | | | Entries without parents are not shown on the web and there isn't any reason to list them here. Such entries belongs to some web services and we have no control over them.
* google: Remove also dir_collisions entriesOndrej Holy2018-09-211-0/+7
| | | | | dir_collisions are not properly invalidated if removed entry is on this list. Let's remove the entry also from this list.
* google: Move debug prints before releasing entryOndrej Holy2018-09-211-2/+2
| | | | | | Debug output contains mess because id and title are const gchar * and are released together with GDataEntry on previous line. Let's just swap the lines.
* Remove workaround for directory / folder iconswip/rishi/issue-2Debarshi Ray2018-08-141-11/+3
| | | | https://gitlab.gnome.org/GNOME/gvfs/issues/2
* google: Drop the (GDestroyNotify) castOndrej Holy2018-07-241-2/+2
| | | | | | | | "warning: function called through a non-compatible type" is printed by GCC 8 because of (GDestroyNotfiy) cast in g_clear_pointer, see for more info: https://gitlab.gnome.org/GNOME/glib/issues/1425. Let's drop the (GDestroyNotify) cast in order to prevent those warnings. The cast was not needed anyway.
* google: Do not create .desktop files for native fileswip/oholy/do-not-use-desktop-filesOndrej Holy2018-07-121-55/+13
| | | | | | | | | | | | | | | Currently, .desktop file with a link to the original location is provided, when a native file is opened because Google doesn't provide its proprietary formats and GLocalFile doesn't know G_FILE_TYPE_SHORTCUT. It is a bit tricky and confusing, among other because the .desktop files aren't automatically converted back to native files when writing. What is worse, Nautilus has dropped support for .desktop files recently, so you see "There was an error launching the application." instead of the requested file. It doesn't make more sense to provide this .desktop files, so let's remove this fallback and return error instead. https://gitlab.gnome.org/GNOME/nautilus/issues/448
* google: Fix compile-time warningBastien Nocera2018-02-281-1/+1
| | | | | | | | | | | | Move the variable into the block where it's used, behind a compile-time version check. gvfs/daemon/gvfsbackendgoogle.c: In function ‘g_vfs_backend_google_query_fs_info’: gvfs/daemon/gvfsbackendgoogle.c:2041:22: warning: unused variable ‘self’ [-Wunused-variable] GVfsBackendGoogle *self = G_VFS_BACKEND_GOOGLE (_self); ^~~~ https://bugzilla.gnome.org/show_bug.cgi?id=793922
* google: Return error when trying to replace native filesOndrej Holy2018-02-081-2/+25
| | | | | | Currently, replacing of google native files silently fails without any error, which may possibly lead to data loss. Let's return an error in this case.
* Add missing casts for g_object_refOndrej Holy2018-02-081-1/+1
| | | | | g_object_ref() currently propagates parameter type to its return value, so type casts needs to be added in order to prevent compiler warnings.
* google: Report FS total size and free spaceMichael Terry2017-08-151-0/+53
| | | | | | | If libgdata 0.17.9 is available, use its new metadata API to query filesystem size and free space and report it back. https://bugzilla.gnome.org/show_bug.cgi?id=785870
* google: Add comment for mutexOndrej Holy2017-08-141-1/+1
| | | | | | | It is not obvious that the mutex guards cache for multi-threaded access. Let's add an comment. https://bugzilla.gnome.org/show_bug.cgi?id=785870
* google: Do not ignore errors when rebuilding cacheOndrej Holy2017-04-211-11/+5
| | | | | | | | If file cache is not loaded properly (e.g. because of cancellation), it may lead to various problems (e.g. incomplete enumeration). Let's return error in such case and rebuild the cache next time... https://bugzilla.gnome.org/show_bug.cgi?id=781252
* google: Fix reported file sizeOndrej Holy2017-03-231-4/+16
| | | | | | | | | Ligdata recently added API to obtain a real file size. Use gdata_documents_entry_get_file_size if libgdata 0.17.7 is available instead of gdata_documents_entry_get_quota_used, which returns 0 in some cases (e.g. shared files). https://bugzilla.gnome.org/show_bug.cgi?id=773053
* google: Prevent potential crashes if resolve_dir failsOndrej Holy2017-03-231-1/+2
| | | | | | | Initialize pointers properly in order to avoid usage of unitialized, or already freed memory. This issues were revealed by coverity scan.
* Use Unicode in translatable stringsPiotr Drąg2016-10-031-7/+7
| | | | | | See https://developer.gnome.org/hig/stable/typography.html https://bugzilla.gnome.org/show_bug.cgi?id=772219
* daemon: Set G_FILE_ATTRIBUTE_FILESYSTEM_REMOTE attributeOndrej Holy2016-06-281-0/+1
| | | | | | | Mark all network-based backends as remote. This is useful to remove some hardcoded lists of filesystem types in GTK+. Bump required GLib version accordingly.
* google: Make a few functions staticRoss Lagerwall2015-11-261-4/+4
| | | | | Silence a few "no previous prototype" warnings from gcc by making the functions static.
* google: Fail in-fs copy/move if it leads to display name lossOndrej Holy2015-10-231-4/+16
| | | | | | | | | Complicated file name handling on google backend leads to display name loss if in-fs copy and move operation is proceeded e.g. using Nautilus. Proper fix will require larger changes for the whole platform. Therefore fail the job preferably to avoid display name loss... https://bugzilla.gnome.org/show_bug.cgi?id=755701
* google: Mark files you can't see on the web as hiddenOndrej Holy2015-10-161-1/+9
| | | | | | | | | | | | Files without the parent are currently shown in google backend root. You can see many files consequently, which are not shown in your google drive folder on the web. Those files can be shared with you, or you opened them in some google applications (i.e. google docs). Mark those files as hidden to see same files as you can see on the web. Also mark the files as undeletable, because it is not possible to delete them from the obvious reason. https://bugzilla.gnome.org/show_bug.cgi?id=756644
* google: Report progress when copying and movingOndrej Holy2015-09-291-0/+7
| | | | | | | | | | Progress isn't reported currently. However it is guaranteed that the progress callback will be called at least after all data has been transferred according the GIO documentation. Nautilus shows some weird progress info when moving and copying consequently. Emit progress callback with total size to fix this issue. https://bugzilla.gnome.org/show_bug.cgi?id=755775
* google: Fix the error string to respect the freeze and for consistencyDebarshi Ray2015-09-101-4/+1
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=754791
View Lorry Controller Status