| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
| |
Currently, critical errors are printed when peer credentials aren't
available (i.e. session bus fallback is used). Let's return an error
immediately to prevent the criticals. Also add warning with suggestion
to allow `--filesystem=xdg-run/gvfsd` access.
https://gitlab.gnome.org/GNOME/gvfs/-/issues/305
|
|
|
|
|
|
|
|
|
|
|
| |
Recently, GVfs switched from abstract sockets to named sockets. The
sockets are created in the `XDG_RUNTIME_DIR` directory. This directory
is not unfortunatelly set for `gvfsd-admin` and thus the root's cache
dir is used instead, which is wrong. Let's pass the `XDG_RUNTIME_DIR`
environment variable to the `pkexec` environment similarly to
`DBUS_SESSION_BUS_ADDRESS`.
Fixes: https://gitlab.gnome.org/GNOME/gvfs/-/issues/552
|
|
|
|
|
|
|
|
|
|
| |
Recently, GVfs switched from abstract sockets to named sockets. The
named sockets honors file permissions and thus the socket owner is root
in the case `gvfsd-admin`. This obviously prevents client from connecting.
Let's change the owner to the value of `PKEXEC_UID` to ensure that the
socket is usable by the client.
https://gitlab.gnome.org/GNOME/gvfs/-/issues/552
|
|
|
|
|
|
|
|
|
|
|
| |
Recently, GVfs switched from abstract sockets to named sockets. The
socket dir is currently created by the individual daemons immediately
before starting DBus server. If gvfsd-admin is started at first, the
socket dir is owned by root user and thus it isn't accesible for other
daemons and clients. Let's create the socket dir early from the gvfsd
daemon to ensure correct ownership.
https://gitlab.gnome.org/GNOME/gvfs/-/issues/552
|
|
|
|
|
|
|
|
|
|
| |
The naming scheme for the non-abstract socket was changed but
`new_connection_data_free` was not adjusted to match.
`GDBusServer` will remove the socket when it stops, but only if
`g_dbus_server_start` was called. So we can simplify the process
somewhat. Also don't bother removing the directory now that all sockets
share it.
|
|
|
|
|
| |
The comment in the .rules file contains `another prompts` phrase which is
wrong. Let's use `another prompt` instead of it.
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
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...
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
| |
GVfs build with --werror fails currently because of glib!1719. Let's
drop the volatile qualifier as it doesn't help with atomicity anyway.
Relates: https://gitlab.gnome.org/GNOME/glib/-/issues/600
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
These backends are special and their "files" are links to locations
from other backends. I doesn't make sense to preview them.
https://gitlab.gnome.org/GNOME/gvfs/-/issues/497
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
filesystem::preview-type used to be IF_LOCAL for this backedn but it
has been unset by commit a71469c79fd31adfc594a55afd29a7ce2202b270
The commit message says it should be treated as remote filesystems.
However, filesystem::remote is set to FALSE, so application would
still interpret this as local for previewing purposes.
Set filesystem::preview-type to get the result expected by that commit.
https://gitlab.gnome.org/GNOME/gvfs/-/issues/497
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The layout of the modal dialogs in gnome-shell changed [1] and the title
now is larger and uses the style of a headline. Make sure all titles
remain fully visible and use shorter strings for those.
Also unify the generic "Enter password" strings a bit to make work
easier for translators and use this string for most cases:
"Authentication Required\nEnter password for “%s”:"
[1] https://gitlab.gnome.org/GNOME/gnome-shell/issues/1343
|
|
|
|
|
|
|
|
| |
gphoto2 does this since commit 983186766060ec82e260f8cd9a5160b93b2ae958
The same rationale applies to MTP.
https://gitlab.gnome.org/GNOME/gvfs/-/issues/497
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The MTP spec section 5.2.2.7 allows `StorageDescription` to be
an empty string.
`libmtp` currently translates this to
char * StorageDescription = NULL
instead of `""` in `ptp_unpack_SI()` via `ptp_unpack_string()`.
(I'm not sure if it's good that it does that, to be followed up on separately.)
`create_storage_name()` until now returned
`g_strdup(storage->StorageDescription)`, which returns `NULL` if `NULL` is
given, and thus `get_storage_info()` would eventually call
char *storage_name = NULL = create_storage_name(storage);
g_file_info_set_name (info, storage_name = NULL);
g_file_info_set_display_name (info, storage_name = NULL);
resulting in assertion failures in `gvfsd`:
g_file_info_set_name: assertion 'name != NULL' failed
g_file_info_set_display_name: assertion 'display_name != NULL' failed
as well as crashes in file managers like Thunar:
g_file_get_child: assertion 'name != NULL' failed
and warnings in Nautilus like:
Got GFileInfo with NULL name in mtp://Ricoh_Company__Ltd._RICOH_THETA_V_00165759/, ignoring. This shouldn't happen unless the gvfs backend is broken.
This commit fixes it by adding a contract to `create_storage_name()`
that it will never represent empty strings as NULL.
|
| |
|
|
|
|
|
|
|
|
| |
It seems that if file monitor is not canceled before unreffing, it can
cause deadlock. Let's explicitly cancel it before unreffing to prevent
this. See https://gitlab.gnome.org/GNOME/glib/-/issues/1941.
Fixes: https://gitlab.gnome.org/GNOME/gvfs/-/issues/485
|
|
|
|
|
|
|
|
| |
Copying file from file:// to admin:// is slow. This is because push
vfunc is not implemented and thus read-write fallback is used. Let's
implement push to improve performance in this case as well.
https://gitlab.gnome.org/GNOME/gvfs/-/issues/530
|
|
|
|
|
|
|
|
| |
Copying file within admin backend is slow in comparison to file://.
This is because copy vfunc is not implemented and thus read-write
fallback is used. Let's implement native copy to improve performance.
Fixes: https://gitlab.gnome.org/GNOME/gvfs/-/issues/530
|
|
|
|
|
|
|
|
|
|
| |
Flatpak applications don't work with gvfs if network access is not
granted. This is because GVfs for peer-to-peer communication uses
abstract sockets, which are tied to the network namespace. Let's use
named sockets under /run/user/$UID/gvfsd/ instead, which will allow
applications to use --filesystem=xdg-run/gvfsd to grant access.
Fixes: https://gitlab.gnome.org/GNOME/gvfs/-/issues/515
|
|
|
|
|
|
|
|
|
|
| |
The G_FILE_ATTRIBUTE_STANDARD_FAST_CONTENT_TYPE attribute is currently
set only if the G_FILE_ATTRIBUTE_STANDARD_CONTENT_TYPE or some other
attributes are requested. Thus it is not set when the fast content type
attribute is requested separately. Let's set the attribute independently
to fix this issue.
Fixes: https://gitlab.gnome.org/GNOME/gvfs/-/issues/529
|
|
|
|
|
|
| |
When moving file from FTP to local filesystem, the remote file is removed
regradless of transfer failure. This is pretty bad as it might lead to data
loss. Let's delete the remote file only if the transfer suceeded.
|
|
|
|
|
|
| |
The output stream is not properly closed in pull job, which might potentially
lead to data loss. Let's use the recently added splice function and close the
output stream with the help of G_OUTPUT_STREAM_SPLICE_CLOSE_TARGET flag.
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
Currently, SFTP backend timeouts when two factor authentication is used
as it doesn't expect another prompt. Let's handle "Verification code"
and "One-time password" prompts and ask user to enter the code.
Fixes: https://gitlab.gnome.org/GNOME/gvfs/-/issues/480
|
|
|
|
|
|
|
|
|
| |
Currently, two connections are established in order to be responsive
even during file transfers. However, this causes duplicated prompts
when ssh-askpass is used. Let's use connection multiplexing instead
to avoid those duplicated prompts.
Fixes: https://gitlab.gnome.org/GNOME/gvfs/-/issues/510
|
|
|
|
|
|
|
|
|
| |
The move operation doesn't report progress currently, however, the
documentation says that it is guaranteed that the prorgress_callback
is called after all data has been transferred. Let's report the
the total number of bytes moved during the operation.
https://gitlab.gnome.org/GNOME/nautilus/-/issues/1635
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The DAV backend tries to find the top-most directory when mounting.
Unfortunatelly, for example with nextcloud.com, the enumeration job
fails with `Method not allowed` error for the root directory found
by this logic:
```
<?xml version="1.0" encoding="utf-8"?>
<d:error xmlns:d="DAV:" xmlns:s="http://sabredav.org/ns">
<s:exception>Sabre\DAV\Exception\MethodNotAllowed</s:exception>
<s:message>Listing members of this collection is disabled</s:message>
</d:error>
```
This is because nextcloud.com prevents listing of its users. Let's
change the mount logic and always require info about children to be
sure that enumeration won't fail later.
Fixes: https://gitlab.gnome.org/GNOME/gvfs/-/issues/468
|
|
|
|
|
|
|
|
| |
Add support for x-gvfs-notrash mount option, which allows to ignore
trash folder on certain mounts. This might be especially useful e.g.
to prevent wakeups of autofs mounts...
https://bugzilla.redhat.com/show_bug.cgi?id=1096200
|
|
|
|
|
|
| |
g_bookmark_file_get_modified is deprecated. Let's port the code to use
g_bookmark_file_get_modified_date_time instead in order to prevent
the deprecation warnings.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Copy and move operations preserve file attributes (such as modification
time) in most of existing scenarios: local copy/move, remote copy/move,
file_copy_fallback in glib. However, one case remains special: copy/move
between local and remote (gvfs) locations. It's implemented by push and
pull operations in backends, which don't attempt to preserve the usual
attributes (e.g., mtime and atime).
This commit implements the missing piece of functionality in sftp
backend. Modification time is preserved on copy and move, and access
time is preserved on move only, complying to the settable attributes
list of sftp backend.
Signed-off-by: Maxim Mikityanskiy <maxtram95@gmail.com>
|
|
|
|
|
|
|
| |
Currently, only Basic and Digest authentication is possible for webdav
backend. Let's add support for NTLM also.
https://gitlab.gnome.org/GNOME/gvfs/issues/342
|
|
|
|
|
|
|
| |
Currently, only Basic and Digest authentication is possible for webdav
backend. Let's add support for Negotiate also.
https://gitlab.gnome.org/GNOME/gvfs/issues/342
|
|
|
|
|
|
|
| |
The new string is not a string freeze breakage, it's already used in a
number of other backends.
Closes: #453
|
|
|
|
| |
We're doing it manually now.
|
|
|
|
|
|
|
|
|
| |
We don't need to go to another function to get an error code when our
switch function does that already.
The "unhandled" AFC errors are now slightly less precise, but it's
still possible to get the meaning of that code from the AFC headers
directly (for developers), and not visible for end-users anyway.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
| |
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).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
User and group are reset when replacing even though
G_FILE_CREATE_REPLACE_DESTINATION is not set. Although the backend
calls SSH_FXP_OPEN with SSH_FILEXFER_ATTR_UIDGID attribute, the OpenSSH
server ignores this attribute in this operation. Let's fix this by the
separate SSH_FXP_FSETSTAT call.
Fixes: https://gitlab.gnome.org/GNOME/gvfs/issues/418
|