| Commit message (Collapse) | Author | Age |
|
|
|
| |
This should help debugging issue #157.
|
|
|
|
|
| |
Slightly increases coverage of examples/passthrough_ll.c (which
supports open for reading, but not for writing).
|
|
|
|
|
|
| |
For example, FreeBSD doesn't have it.
Fixes: #173.
|
|
|
|
| |
Fixes: #160.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently libfuse has a hardcoded buffer limit to 128kib, while fuse
kernel module has a limit up to 32 pages.
This patch changes buffer limit to match the current page size, instead
of assuming 4096 bytes pages, enabling architectures with bigger pages
to use larger buffers, improving performance.
Also, add a new macro (HEADER_SIZE) to specify the space needed to
accommodate the header, making it easier to understand why those extra
4096 bytes are needed
Signed-off-by: Carlos Maiolino <cmaiolino-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
In particular, don't call it "user_data" in one place and
"private_data" elsewhere.
Changing the name of the variable in the prototype should not affect
backwards compatibility.
Fixes: #155.
|
| |
|
| |
|
| |
|
|
|
|
| |
Together with the previous commit, this fixes #156.
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
Since os.path.join() interprets leading slashes, we were
actually never accessing the mountpoint and doing all the
tests in the source directory.
Fixes: #139
|
|
|
|
|
|
| |
This allows calls like open(file, O_CREAT|O_RDONLY, 0200) which would
otherwise fail because we cannot open the file after mknod() has
created it with 0200 permissions.
|
|
|
|
|
| |
No reason not to use it. May even be a little faster and will
consume less resources :-).
|
|
|
|
|
| |
This allows truncating an open file even if write permission
was removed after open() (which is the expected behavior).
|
|
|
|
| |
That way we can use the file descriptor for other operations.
|
|
|
|
| |
Required for better hardlink handling, see comments in patch.
|
|
|
|
|
| |
That way, we are not drowning in messages when a test would also fail
without debugging enabled.
|
| |
|
|
|
|
|
|
| |
This appeared to work because of an unrelated bug that caused us to
actually never access the mountpoint at all and do all tests on the
lower filesystem. This issue will be fixed in a separate commit.
|
| |
|
| |
|
|
|
|
|
| |
There is no reason why so many tests require the file system
to support unlink() and/or rmdir().
|
|
|
|
|
| |
Ensure that we are really creating a new file.
Don't attempt to write, we do that in tst_open_write().
|
|
|
|
|
| |
We are actually testing both opening of an existing file
and writing to it.
|
|
|
|
| |
To check for unlink() support without requiring create()/mknod().
|
|
|
|
|
| |
This allows testing a filesystem that offers mkdir(), but no
rmdir() (and vice versa).
|
|
|
|
|
| |
This makes more sense, since we are specifically checking
unlinking of an open file.
|
|
|
|
|
|
| |
By creating the files in the lower filesystem, we
can test readdir() even for filesystems that don't implement
create() or mkdir().
|
| |
|
| |
|
|
|
|
| |
See also issue #148.
|
|
|
|
| |
No longer supported in Meson 0.39.
|
| |
|
|
|
|
|
| |
The FUSE_CAP_ATOMIC_IO_TRUNC capability is enabled by default,
but we didn't update the open() documentation accordingly.
|
|
|
|
| |
Fixes #138.
|
|
|
| |
Redundant copy when only op.read is available removed.
|
|
|
|
| |
Putting it in CFLAGS interferes with feature detection.
|
|
|
|
|
| |
Defining it in the file causes trouble because Meson sometimes
inserts includes before the first line.
|
| |
|
| |
|
| |
|
|
|
|
| |
This triggered undefined behaviour warnings from UBSan.
|
|
|
|
|
|
|
|
|
|
|
|
| |
The permission caching bug has been present forever, is presumably
going to stay around for a while, and is of less concern if
allow_other is not used. Since allow_other is disabled by default, I
think we can safely make this warning less prominent and document the
problem when we describe allow_other.
Also, drop the travis build status. It's confusing when reading
README.md after extracting the tarball, and I am not sure who benefits
from the build status when it is shown on GitHub either.
|
| |
|
| |
|