| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
See https://developer.gnome.org/hig/stable/typography.html
https://bugzilla.gnome.org/show_bug.cgi?id=772219
|
|
|
|
|
|
|
|
| |
Dav backend always tries to mount WebDAV share with the shortest prefix.
Unfortunately, it never tries the root when looking for it excepting
the case, when the root is already specified.
https://bugzilla.gnome.org/show_bug.cgi?id=770549
|
|
|
|
|
|
|
| |
If we have a DAV share, ie proper DAV header and good PROPFIND call
but we are not in a collection we report a better error message.
https://bugzilla.gnome.org/show_bug.cgi?id=770549
|
|
|
|
|
|
|
|
|
|
| |
If the user cancels the authentication dialog during the mount
operation, we should catch that case and instead of returing
G_IO_ERROR_FAILED we should G_IO_ERROR_FAILED_HANDLED. This will
prevent an (expected) error being back to the user. This is in
line with what other backends do in the same situation.
https://bugzilla.gnome.org/show_bug.cgi?id=770549
|
|
|
|
|
|
| |
Free the two messages use for mount root detection in case of error.
https://bugzilla.gnome.org/show_bug.cgi?id=770549
|
|
|
|
|
|
|
|
|
| |
If we can detect that a location is not a webdav share then prefer
that error message over any other. For other error cases also take
errors from the PROPFIND call into account. Translate the status
code into a proper GIO error code.
https://bugzilla.gnome.org/show_bug.cgi?id=770549
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
| |
It is not possible to mount WebDAV share with IPv6 address currently.
GMountSpec host contains brackets around the IPv6 address, however SoupURI
doesn't. This patch handles this when converting GMountSpec to SoupURI
and vice versa.
https://bugzilla.gnome.org/show_bug.cgi?id=766631
|
|
|
|
|
|
| |
Otherwise nautilus will offer the wrong action in its UI.
https://bugzilla.gnome.org/show_bug.cgi?id=753934
|
|
|
|
|
|
|
| |
This attribute was being set inconsistently, and is used by the file
chooser.
https://bugzilla.gnome.org/show_bug.cgi?id=752834
|
|
|
|
|
|
|
|
|
|
| |
For progress in applications like Nautilus to be shown correctly, they
need at least one progress callback to be emitted at the end. This is
supposed to be guaranteed according to the GIO documentation. With
server-side copy and move using webdav, emit a single progress callback
at the end with the source file size.
https://bugzilla.gnome.org/show_bug.cgi?id=749354
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When mounting a secure webdav share, verify the certificate using the
system certificate store, or if that is not possible, ask the user
whether it is OK.
ssl-strict is enabled for the SoupSession. If the first connection
attempt fails, the certificate is presented to the user. If they agree
to the certificate, then it is stored and compared with the certificate
presented on each subsequent connection. It is an error if the
certificate changes.
https://bugzilla.gnome.org/show_bug.cgi?id=708306
|
|
|
|
|
|
|
|
|
|
| |
Mime type octet-stream is set when writing since commit 635c3b5,
because soup_message_set_request requires to be called with mime type
and we don't know it. Unfortunatelly some servers returns this mime
type for written files instead of real mime type. Use
soup_message_body_append instead without mimetype to fix this issue.
https://bugzilla.gnome.org/show_bug.cgi?id=687757
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=744078
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=743379
|
|
|
|
|
|
|
| |
Don't leak the source and target URI when doing a server-side move.
Also, don't continue after giving an G_IO_ERROR_EXISTS.
https://bugzilla.gnome.org/show_bug.cgi?id=743379
|
|
|
|
|
|
|
|
| |
Use webdav's COPY method to implement support for server-side copying.
This improves performance considerably, especially over slow
connections.
https://bugzilla.gnome.org/show_bug.cgi?id=743379
|
|
|
|
|
|
|
|
|
| |
path_equal tries to unescape path before comparing. Unfortunately
this function is used also for already unescaped paths. Therefore
unescaping can fail. This commit reverts changes which was done in
commit 50af53d and unescape just uris, which aren't unescaped yet.
https://bugzilla.gnome.org/show_bug.cgi?id=743298
|
|
|
|
|
|
|
|
|
|
| |
Move operation fails immediately with G_IO_ERROR_CANT_CREATE_BACKUP if
G_FILE_COPY_BACKUP is specified. Consequently copy and delete fallback
isn't executed. Return NOT_SUPPORTED instead of CANT_CREATE_BACKUP to
proceed with the fallback if G_FILE_COPY_NO_FALLBACK_FOR_MOVE isn't
specified.
https://bugzilla.gnome.org/show_bug.cgi?id=740057
|
|
|
|
|
|
|
|
|
| |
When writing a large amount to a GMemoryOutputStream, the reallocation
function can fail. Use g_try_realloc so that failures generate
G_IO_ERROR_NO_SPACE rather than abort the process (as happens with
g_realloc).
https://bugzilla.gnome.org/show_bug.cgi?id=739428
|
|
|
|
|
|
|
|
|
|
| |
Ignore parameters of the file's content type since these break
applications which make use of the content type.
E.g. If the server returns a type such as "text/plain; charset=utf-8",
the file won't open in a text editor.
https://bugzilla.gnome.org/show_bug.cgi?id=676627
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=594507
|
|
|
|
|
|
|
| |
Force unmount the backend when the resolved data changes (most likely
when the remote service disappears).
https://bugzilla.gnome.org/show_bug.cgi?id=594507
|
|
|
|
|
|
|
| |
Send a "success" response earlier when enumerating to allow infos to be
sent incrementally rather than batched up until the end.
https://bugzilla.gnome.org/show_bug.cgi?id=734695
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since libsoup 2.42.0, SoupSessionSync/SoupSessionAsync are deprecated,
and replaced by direct use of SoupSession as described on
https://developer.gnome.org/libsoup/stable/libsoup-session-porting.html
This commit removes use of SoupSessionSync/SoupSessionAsync and adjusts
the code according to the advice in the doc above:
- we only need one SoupSession instance as sync/async calls are
made depending on the SoupSession method we use, not depending
on the instance type
- SoupSession already comes with a SoupProxyResolverDefault, we don't
need to add it ourselves
- SoupSession already comes with a SoupContentDecoder, we don't
need to add it ourselves
- SoupSession:use-thread-context is now unused and always set to TRUE,
so we don't need to change it
To prevent any changes in behavior, we set ssl-strict to FALSE.
(Patch updated by Ross Lagerwall)
(Reapplying now that #732783 and #732925 have been fixed.)
https://bugzilla.gnome.org/show_bug.cgi?id=708306
https://bugzilla.gnome.org/show_bug.cgi?id=732090
|
|
|
|
|
|
|
|
| |
This reverts commit 4b76a7e10d76b26929425dc8a392bf0cee246b98.
Reverting for now since this has concurrency with libsoup:
https://bugzilla.gnome.org/show_bug.cgi?id=732783
https://bugzilla.gnome.org/show_bug.cgi?id=732925
|
|
|
|
|
|
| |
Path is always non-NULL. Set a path to "/" instead of NULL.
https://bugzilla.gnome.org/show_bug.cgi?id=732090
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since libsoup 2.42.0, SoupSessionSync/SoupSessionAsync are deprecated,
and replaced by direct use of SoupSession as described on
https://developer.gnome.org/libsoup/stable/libsoup-session-porting.html
This commit removes use of SoupSessionSync/SoupSessionAsync and adjusts
the code according to the advice in the doc above:
- we only need one SoupSession instance as sync/async calls are
made depending on the SoupSession method we use, not depending
on the instance type
- SoupSession already comes with a SoupProxyResolverDefault, we don't
need to add it ourselves
- SoupSession already comes with a SoupContentDecoder, we don't
need to add it ourselves
- SoupSession:use-thread-context is now unused and always set to TRUE,
so we don't need to change it
To prevent any changes in behavior, we set ssl-strict to FALSE.
(Patch updated by Ross Lagerwall)
https://bugzilla.gnome.org/show_bug.cgi?id=708306
https://bugzilla.gnome.org/show_bug.cgi?id=732090
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=729938
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Implement push support for the webdav backend. This allows large files
to be uploaded properly without consuming large amounts of memory and
also makes the progress bar work when uploading.
Data is provided to libsoup in chunks, activated via the wrote_chunk
signal. Note that this uses content-length encoding rather than chunked
encoding which is not supported by many servers. The CAN_REBUILD flag
is set on the SoupMessage and accumulate is set to FALSE so that Libsoup
does not buffer all the data in memory at once. This does mean that the
restarted signal needs to be handled correctly by seeking to the
beginning of the file.
The code is written in an asynchronous fashion so that other operations
are not blocked since the webdav backend is single-threaded.
Unfortunately, this does complicate the code, especially with regards to
having reads in flight and handling the restarted signal from libsoup.
A quick benchmark writing to a tmpfs via Apache's mod_dav achieved
just over 1GB/s.
https://bugzilla.gnome.org/show_bug.cgi?id=570772
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This saves unnecessary round trips when moving files and directories.
Based on a patch by Mads Chr. Olesen and the GLocalFile implementation.
Backups are not yet implemented. It tries to cover the various cases of
overwriting files with directories and vice versa by doing what
GLocalFile does. Notably, webdav servers are capable of overwriting a
directory with a file which is not a supported operation for
g_file_move, while at least Apache's mod_dav gives a generic 400 Bad
Request when trying to overwrite a file with a directory.
https://bugzilla.gnome.org/show_bug.cgi?id=572786
|
|
|
|
|
|
|
| |
Have a single function which converts libsoup error codes to gio error
codes rather than one in each backend.
https://bugzilla.gnome.org/show_bug.cgi?id=536305
|
|
|
|
|
|
|
|
| |
In some instances (e.g. Apache), gvfs uses percent encodings like %2A
while Apache returns redirections encoded like %2a. This makes
redirections fail when non-ascii characters are used in the path.
https://bugzilla.gnome.org/show_bug.cgi?id=721543
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=720062
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=720062
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=720275
|
|
|
|
|
|
|
| |
Report the number of bytes used by exposing the "quota-used-bytes"
property.
https://bugzilla.gnome.org/show_bug.cgi?id=712654
|
|
|
|
|
|
|
|
| |
Some servers send empty resourcetype nodes or don't send the node at all
for regular files (the spec says that it defaults to empty). Set the
file type to regular by default.
https://bugzilla.gnome.org/show_bug.cgi?id=706798
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=695834
|
|
|
|
|
|
|
|
| |
The content_type argument is required to be set for soup_message_set_request()
if passing data in. Using "application/octet-stream" makes it work,
though I'm not sure whether it's accepted by all dav servers.
https://bugzilla.gnome.org/show_bug.cgi?id=687757
|
|
|
|
|
|
|
|
|
|
|
| |
SoupOutputStream was never particularly useful, since we ended up not
doing chunked requests (since server support for them is mostly
nonexistent). So kill SoupOutputStream off and just use a
GMemoryOutputStream instead.
https://bugzilla.gnome.org/show_bug.cgi?id=687757
Signed-off-by: Tomas Bzatek <tbzatek@redhat.com>
|
|
|
|
|
|
|
|
|
|
| |
gvfsbackendhttp defined g_vfs_job_failed_from_http_status(), but
didn't export this, so gvfsbackenddav was sort of forced to
reimplement it. Fix that by exporting it as http_job_failed().
https://bugzilla.gnome.org/show_bug.cgi?id=687757
Signed-off-by: Tomas Bzatek <tbzatek@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Replace the hacky SoupInputStream with a new GVfsHttpInputStream that
is a wrapper around SoupRequest. (We need a wrapper stream rather than
just using SoupRequest directly because we want the stream here to be
seekable, which requires cancelling and re-sending the HTTP request
and getting a new underlying stream.)
The http and dav backends still use both a sync and an async
SoupSession, even though this is no longer necessary, since changing
this would require a lot of rewriting of code that currently works.
https://bugzilla.gnome.org/show_bug.cgi?id=687757
Signed-off-by: Tomas Bzatek <tbzatek@redhat.com>
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=682990
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The backend protocol isn't necessary in the display name for a
location. And having it there makes it much harder to actually
find the user interesting part of the name. Once a mount is connected
the user interesting part of the name is "what it is" and not
"how it is accessed".
This is possible now that we aren't using the display name
to make a unique mount point.
https://bugzilla.gnome.org/show_bug.cgi?id=682878
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=681458
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Updating the address of the FSF.
This has been done by:
while read file; do
sed -i 's:59 Temple Place:51 Franklin Street:' $file
sed -i 's:Suite 330:Fifth Floor:' $file
sed -i 's:02111-1307:02110-1301:' $file
done
https://bugzilla.gnome.org/show_bug.cgi?id=656598
Signed-off-by: Tomas Bzatek <tbzatek@redhat.com>
|
|
|
|
|
|
|
|
|
| |
The webdav root finding logic has been changed so it will not
continue to check the parent directory if we did not get a
webdav collection.
Also if we successfully obtained the information for a directory
we switch the auth handler to non-interactive so we don't try
to ask for new credentials for parent dir. Fix bug #677753.
|
|
|
|
|
|
|
|
| |
The old logic in ms_response_to_file_info () assumed that all
the tags that were present in the 200 status block of the
multistatus response actually contain data. Of course some
server will violate this assumption. We now make sure that tags
really have content when parsing. Should fix bug 675506.
|
|
|
|
|
| |
Based on patch by Gareth Bult
https://bugzilla.gnome.org/show_bug.cgi?id=669258
|