| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
| |
The fuse daemon can fail when client attempts to seek backwards and seek
is not supported by the concrete backend. There is fallback for forward
seeks using `g_input_stream_skip`. Let's reopen the file and use the same
approach also for backwards seeks. This is pretty ugly to reopen the file
but similar approach is used already to emulate read/write mode.
Fixes: https://gitlab.gnome.org/GNOME/gvfs/issues/441
|
|
|
|
|
|
| |
If `G_FILE_ATTRIBUTE_TIME_MODIFIED` is not set for some reason, the
fuse daemon aborts as it expects that it is always set. Let's use
g_file_info_has_attribute to prevent the crashes.
|
|
|
|
|
| |
GTimeVal is deprecated. Let's remove it in order to prevent the
deprecation warnings.
|
|
|
|
|
|
| |
Remove unnecessary while loop since g_input_stream_read_all
and g_output_stream_write_all guarantee that all data is
read/written when exiting successfully.
|
|
|
|
|
|
|
|
|
|
| |
Since we moved to fuse 3 big_writes are enabled by default.
There is no need to manually specify max_write anymore since the
set value is actually smaller than the libfuse default.
Let libfuse figure out the right value.
This increses the transfer speed from 31MiB/s to 43MiB/s between
my system and a SMB share.
|
|
|
|
|
|
| |
These macros exist in Linux headers, but they don't exist on FreeBSD.
Since fuse library always uses the same values regardless of the
platform, we just define them ourselves when they aren't defined.
|
|
|
|
|
|
|
|
|
|
| |
Gvfsd-fuse required the old 2.x versions of fuse. Fuse developers
encourage developers to transition to the actively developed libfuse
3.x. This change adapt gvfsd-fuse to build with fuse 3.x. Note that
fuse is no longer compatible with fuse 2.x. It now requires fuse 3.0.0
or later to build.
Closes: https://gitlab.gnome.org/GNOME/gvfs/issues/323
|
|
|
|
|
|
|
| |
Filesystem sizes can be large and in danger of overflowing. Guard
against that possibility in the dav and fuse FS query code.
https://bugzilla.gnome.org/show_bug.cgi?id=786177
|
|
|
|
|
|
| |
File handle may be NULL, so it has to be checked before dereferencing.
This issue was revealed by coverity scan.
|
|
|
|
|
| |
It is hard to debug what application is accessing fuse mount point.
Let's add client pid in the debug messages.
|
|
|
|
|
| |
There is a lot of messages if all debug output from gvfs is enabled.
Let's add prefixes in order to find easily origin of the messages.
|
|
|
|
|
| |
Debug prints contain open flags as an octal numbers, which is hard
to read. Print selected flags in readable form for easier debugging.
|
|
|
|
|
|
|
|
|
|
| |
It was not possible to enable debug output from the fuse daemon without
rebuilding. This patch replaces custom debug handling in the similar way
as it is done in other daemons (using GLib logging functionality).
Environment variable GVFS_DEBUG_FUSE can be specified in order to enable
debugging and SIGUSR2 signal can be sent also to toggle debug output.
The debug output will be printed at stdout, so the debug output can be
seen on gvfsd output thanks to the commit 85bacbf.
|
|
|
|
|
|
|
|
|
|
| |
Fuse removes its signals handlers in the middle of exit procedure,
before vfs_destroy() call. Consequenlty fuse daemon may be killed
instead of proper termination if signal is recieved. Reimplement
fuse_main helper using lowlevel API in order to ignore new signals
during the whole exit procedure.
https://bugzilla.gnome.org/show_bug.cgi?id=762250
|
|
|
|
|
|
|
|
|
| |
There may be a race when exiting between a fuse main loop and
a subthread's main loop. Therefore call g_main_loop_quit always
from vfs_destroy on the main thread and wait there for a termination
of the subthread to avoid the race.
https://bugzilla.gnome.org/show_bug.cgi?id=762250
|
|
|
|
|
|
| |
Result from g_vfs_get_default shouldn't be freed as per documentation.
https://bugzilla.gnome.org/show_bug.cgi?id=762250
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
If a file is open for reading and writing, ensure to pass the O_APPEND
flag if necessary when reopening the output stream. This allows a
write-read-write sequence to work properly if the file is opened for
O_APPEND. The O_TRUNC flag is not passed since this would cause a
write-read-write sequence to truncate the file on the second write. As
it is, the second write fails with ENOTSUP since this kind of operation
is not supported by GVFS.
https://bugzilla.gnome.org/show_bug.cgi?id=632296
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before, if an application created, dup()ed the fd and then closed it,
the stream would be closed. When attempting to write to the original
fd, reopening the stream would fail since it is an error to open an
existing file without either truncating it or appending to it.
Close the stream on release() rather than flush() to fix this since
release() is called only once per open/create rather than for each
close. Since g_output_stream_flush() is called after every write,
flush() and fsync() are unnecessary.
https://bugzilla.gnome.org/show_bug.cgi?id=632296
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, if a getattr() for an open file could not get the size
information, the file position was returned as the size. This is
incorrect if seek or ftruncate had previously been used on the stream.
Instead, track the size of the open file and return this value. In
addition, use this size in preference to the size returned by
g_file_query_info() if a stream is open (this only happens if the stream
doesn't support g_file_query_info_on_write()) since the tracked size is
more likely to be correct due to implementing g_file_replace by writing
to a temporary file. Tracking the size is only necessary for files
which are created or opened with O_TRUNC since files opened with
O_APPEND will be appended in-place.
https://bugzilla.gnome.org/show_bug.cgi?id=632296
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Because g_file_append_to opens an output stream that can only append
regardless of the seek position, only use g_file_append_to when O_APPEND
is actually specified. This prevents file corruption when the mode is
O_WRONLY or O_RDWR without O_APPEND.
Note that this means opening a file with a bare O_WRONLY or O_RDWR
returns ENOTSUP since there is no equivalent in gvfs.
Furthermore, don't attempt to seek when the file mode is O_APPEND since
this is unnecessary.
https://bugzilla.gnome.org/show_bug.cgi?id=632296
|
|
|
|
|
|
|
|
|
| |
When truncating, if a writable stream is open, truncate that rather than
using g_file_replace on the path since that fails to have the desired
effect if replace is implemented by writing to a temporary and then
renaming.
https://bugzilla.gnome.org/show_bug.cgi?id=632296
|
|
|
|
|
|
|
|
|
|
| |
If a stream is open and it supports query_info_on_{read,write}, use that
in preference to querying the file using the path. This causes the
correct information to be retrieved when g_file_replace is implemented
by writing to a temporary file, rather than the information of the
yet-to-be-replaced file.
https://bugzilla.gnome.org/show_bug.cgi?id=632296
|
|
|
|
|
|
|
|
|
| |
vfs_rename incorrectly maps EISDIR to EXDEV when renaming. However,
EISDIR occurs when the source is a file and the destination is a
directory and it shouldn't be remapped. (G_IO_ERROR_WOULD_RECURSE is
mapped to EXDEV instead.)
https://bugzilla.gnome.org/show_bug.cgi?id=734568
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
G_IO_ERROR_WOULD_MERGE
This patch adds the following GError to errno mappings to
errno_from_error():
G_IO_ERROR_WOULD_RECURSE -> EXDEV
G_IO_ERROR_WOULD_MERGE -> ENOTEMPTY
The first mapping is required to allow 'mv' to rename/move a
directory in a gvfs-fuse directory that belongs to a backend
without support for a native move operation. In such cases,
g_file_move() returns G_IO_ERROR_WOULD_RECURSE, which needs to
be mapped to -EXDEV in order for mv to fall back to recursive
copy & delete operation.
Similarly, G_IO_ERROR_WOULD_MERGE is returned when trying to
move/merge two non-empty directories. By mapping it to -ENOTEMPTY,
the error message returned by 'mv' becomes ": Directory not empty"
instead of generic ": Input/output error".
https://bugzilla.gnome.org/show_bug.cgi?id=734568
Signed-off-by: Rok Mandeljc <rok.mandeljc@gmail.com>
|
|
|
|
|
|
|
|
| |
If the GFileInfo has a UNIX mode available, use that for setting
permissions. This prevents programs like vim from losing permissions
when saving a file.
https://bugzilla.gnome.org/show_bug.cgi?id=727996
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=712382
|
|
|
|
|
|
|
| |
If a filesystem is 4095 bytes, indicate that it uses 1 block rather than
0 blocks.
https://bugzilla.gnome.org/show_bug.cgi?id=711855
|
|
|
|
|
|
|
|
| |
Without the big_writes option, fuse uses a block size of 4096 bytes
which results in poor write performance. So use the big_writes option
to write blocks up to 64KiB in size.
https://bugzilla.gnome.org/show_bug.cgi?id=652540
|
|
|
|
|
|
|
| |
Instead of failing in read() with ENOTSUPP after the lseek on a
nonseekable stream succeeds, make the lseek fail with ESPIPE, as it
should. This is important for applications which test the return value
of lseek to determine if the file descriptor is seekable.
|
|
|
|
|
|
|
|
| |
When running multithreaded, fuse can issue readahead requests out of
order which can cause subsequent reads to fail with ENOTSUPP (if seeking
backward is not supported on the stream).
Force readahead to occur in order to prevent this problem.
|
|
|
|
|
|
|
|
|
| |
Since fh->pos is already incremented by n_bytes_skipped, check if
offset == fh->pos.
This error was hidden by the fact that the operation is retried when
-EIO is returned. When it was retried, the stream was already in the
correct position and so no seek operation was required.
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=695834
|
| |
|
|
|
|
|
| |
Don't try to seek if there was an error during padding. Also report
seek errors.
|
|
|
|
|
|
| |
See http://git.gnome.org/browse/glib/commit/?id=2002479c02fa6e468fc3f67ddc663657a52ebde8
https://bugzilla.gnome.org/show_bug.cgi?id=687236
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=685248
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=682878
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
| |
Don't allocate whole padding block, write in smaller pieces instead.
As an bonus, check for block write result and break if error occurred,
passing it further up.
Found by David Zeuthen.
|
|
|
|
|
|
|
|
|
|
| |
When ftruncate is called with a size greater than the current size
of the file, the expected behavior is that the file size increases to
the requested size, and the new space is zero-filled. SQLite depends
on this behavior when opening a database using 'write-ahead log'
journaling.
Based on original patch by Jeff Smith <whydoubt@yahoo.com>
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=583927
|
|
|
|
|
|
| |
Turned out zeroing memory is not enough in some cases so let's be
on the safe side and properly initialize all non-static mutexes.
Also, don't initialize/clear the static ones.
|
|
|
|
| |
Last piece in order to fix https://bugzilla.gnome.org/show_bug.cgi?id=661148
|
|
|
|
| |
A continuation to https://bugzilla.gnome.org/show_bug.cgi?id=661148
|
|
|
|
|
|
|
| |
GStaticMutex and GStaticRWLock have been replaced by GMutex
and GRWLock, and g_thread_init() is no longer needed.
https://bugzilla.gnome.org/show_bug.cgi?id=661148
|
|
|
|
|
| |
GLib recently became less forgiving about single includes
like this.
|