Hello tech@
Due to the challenges of having a large diff reviewed I've had another
think about how I can break up the FUSE changes so that they are smaller
and easier to review.
This is the first of these diffs.
The current design uses a fixed size fusebuf that consists of a header
and a union
On Fri, Feb 05, 2021 at 07:17:09PM +0100, Gr??goire Jadi wrote:
> Helg writes:
>
> Hi,
>
> > I currently only have a port of the 2.x branch of libfuse (attached) but
> > will also port the 3.x libfuse once I have user mounting working. I am
> > not aware of a
On Mon, Nov 27, 2017 at 10:48:04AM +0100, Martin Pieuchot wrote:
> On 23/11/17(Thu) 21:45, Helg wrote:
> > On Thu, Nov 23, 2017 at 12:09:34PM +0000, Helg Bredow wrote:
> > > - Forwarded message from Martin Pieuchot <m...@openbsd.org> -
> > >
> >
fusefs_link returns the wrong error code when attempting to create a
hard link to a directory. It returns EISDIR when it should instead
return EPERM. Discovered while running the ffs test suite on ntfs-3g
and confirmed by comparing to ufs.
This is the description for the test that fails:
"link
Hi tech@
It should not be possible to create a file or directory if write
permission is denied on the parent directory of the file or directory to
be created. However, FUSE does not perform an access check when the new
vnode lookup is performed and always allows files and directory to be
created
This patch adds support for the -f option, which forces the FUSE file
system to run in the foreground. This is useful for debugging and adds
a missing feature to the library.
ok?
Index: fuse.c
===
RCS file:
When renaming a file on a FUSE file system and the target exists and is
open, a deadlock will occur because the target vnode (tvp) has not been
unlocked by fusefs_rename(). When the process that has the file open
calls close(2) the vnode will still be locked with no chance of ever
being unlocked.
The VOP_LOOKUP(9) man page incorrectly states the following about
VOP_RENAME(9).
"If not NULL, tvp will be locked on return as well."
However, dorenameat() in /sys/kern/vfs_syscalls.c unlocks tvp on error
and file systems unlock it on success. This patch changes this line to
read "unlocked".
On Thu, Nov 23, 2017 at 12:09:34PM +, Helg Bredow wrote:
> - Forwarded message from Martin Pieuchot <m...@openbsd.org> -
>
> Date: Sat, 18 Nov 2017 11:03:49 +0100
> From: Martin Pieuchot <m...@openbsd.org>
> To: Helg Bredow <xx...@msn.com>
> CC:
On Fri, 10 Nov 2017 09:09:32 +0100
Martin Pieuchot <m...@openbsd.org> wrote:
> On 09/11/17(Thu) 01:20, Helg Bredow wrote:
> > > On 08/11/17(Wed) 14:12, Helg Bredow wrote:
> > > > There is a bug when creating a file in fuse-exfat and then deleting it
> > > &g
On Fri, 10 Nov 2017 11:55:53 +
Helg Bredow <xx...@msn.com> wrote:
> On Fri, 10 Nov 2017 10:13:35 +0100
> Anton Lindqvist <an...@openbsd.org> wrote:
>
> > On Fri, Nov 10, 2017 at 09:36:25AM +0100, Martin Pieuchot wrote:
> > > On 09/11/17(Thu) 09:02, He
On Fri, 10 Nov 2017 10:13:35 +0100
Anton Lindqvist <an...@openbsd.org> wrote:
> On Fri, Nov 10, 2017 at 09:36:25AM +0100, Martin Pieuchot wrote:
> > On 09/11/17(Thu) 09:02, Helg Bredow wrote:
> > > The current libfuse signal handling assumes that the file system will
&
The current libfuse signal handling assumes that the file system will always be
unmounted by the child. One obvious case where this is not true is if the file
system is busy. To replicate:
1. mount a fuse file system
2. cd anywhere on the file system
3. pkill -INT
The result is a zombie child
On Wed, 8 Nov 2017 16:50:07 +0100
Martin Pieuchot <m...@openbsd.org> wrote:
> On 08/11/17(Wed) 14:12, Helg Bredow wrote:
> > There is a bug when creating a file in fuse-exfat and then deleting it
> > again without first unmounting the file system. The reason for this i
There is a bug when creating a file in fuse-exfat and then deleting it
again without first unmounting the file system. The reason for this is
that fuse-exfat maintains strict reference counts and fuse currently
calls the file system create and open functions when it should only
call create. The
The fuse_version() library function incorrectly returns FUSE_USE_VERSION. This
macro is intended to be used by file systems to indicate the version of the
libfuse API to compile against. This change returns the highest version of the
API that libfuse supports. Both macros have the same value so
The library function fuse_loop_mt() is currently unimplemented. It should
return -1 to indicate failure rather than claim success when it clearly didn't
do anything useful. fuse_loop_mt() should never be called by file systems since
fuse_parse_cmdline() and fuse_setup() alway return 0 as the
On Sat, 28 Oct 2017 10:07:39 +0200
Martin Pieuchot <m...@openbsd.org> wrote:
> On 17/10/17(Tue) 14:26, Helg Bredow wrote:
> > [...]
> > I've split the patch. This one improves argument and option parsing so that
> > almost all sshfs arguments and options will no
On Sat, 28 Oct 2017 09:24:55 +0200
Martin Pieuchot <m...@openbsd.org> wrote:
> On 25/10/17(Wed) 13:27, Helg Bredow wrote:
> > I've included different minor patches below as one patch. I haven't split
> > into separate patches since the changes are not complex and easy to au
These tests confirm that currently supported options are parsed correctly by
libfuse. They assume that the patches I've submitted previously have been
applied.
Review and suggestions for improvement are welcome.
Patch to Makefile is below and new tests are attached.
Index: Makefile
I've included different minor patches below as one patch. I haven't split into
separate patches since the changes are not complex and easy to audit.
Here's what it does:
Almost all functions in fuse.c do not check if the arguments are null. This
patch adds null checks where appropriate.
Some
Arguments to fuse_parse_cmdline() are not checked for NULL before assignment.
This patch performs the check.
Index: fuse.c
===
RCS file: /cvs/src/lib/libfuse/fuse.c,v
retrieving revision 1.30
diff -u -p -u -p -r1.30 fuse.c
---
On Wed, 18 Oct 2017 15:03:21 +0200
Martin Pieuchot <m...@openbsd.org> wrote:
> On 18/10/17(Wed) 12:51, Helg Bredow wrote:
> > On Wed, 18 Oct 2017 10:04:07 +0200
> > Martin Pieuchot <m...@openbsd.org> wrote:
> >
> > > On 17/10/17(Tue) 15:30, Helg Bredow
On Wed, 18 Oct 2017 10:04:07 +0200
Martin Pieuchot <m...@openbsd.org> wrote:
> On 17/10/17(Tue) 15:30, Helg Bredow wrote:
> > If you execute "fuse-zip -V" it prints the version and then dumps core.
> > This is because fuse-zip does not initialise the mount point p
If you execute "fuse-zip -V" it prints the version and then dumps core. This is
because fuse-zip does not initialise the mount point pointer to NULL. This
patch ensures that it's always initialised to NULL.
Index: fuse.c
===
RCS
On Mon, 16 Oct 2017 15:33:45 +0200
Martin Pieuchot <m...@openbsd.org> wrote:
> On 14/10/17(Sat) 01:23, Helg Bredow wrote:
> > The attached patch vastly improves fuse argument and option parsing. For
> > example, all sshfs options will now be parsed successfully. It's a
are not supported and/or recognised yet and this would prevent those file
systems from running.
I'm happy to take feedback and recommendations.
--
Helg <xx...@msn.com>
libfuse-20171014.diff
Description: libfuse-20171014.diff
fuse-opt-parse-regress.diff
Description: fuse-opt-parse-regress.diff
On Sat, 21 Feb 2015 12:56:00 +0100
Stefan Sperling s...@stsp.name wrote:
On Sun, Feb 22, 2015 at 12:55:35AM +0800, Helg wrote:
Hi All,
I’ve spent a bit more time hacking on fuse and while it still has some
way to go, the attached patch moves it forward in the right direction.
I’d
parsing so that comma separated options are now
supported
3. Unlinking or renaming an open file no longer causes the kernel to
get sick
4. Support for -d option so fuse does not demonise
--
Helg xx...@msn.com
fuse.diff
Description: Binary data
libfuse.diff
Description: Binary data
); \
panic(vp not locked); \
+} \
} while (0)
#else
#define ASSERT_VP_ISLOCKED(vp) /* nothing */
--
Helg xx...@msn.com
Anyone?
); \
panic(vp not locked); \
+} \
} while (0)
#else
#define ASSERT_VP_ISLOCKED(vp) /* nothing */
--
Helg xx...@msn.com
On Sat, 10 Jan 2015 19:39:19 -0800
Philip Guenther guent...@gmail.com wrote:
On Mon, 5 Jan 2015, Helg wrote:
The man page for LOCK(9) says that if the kernel option LOCKDEBUG is
enabled, additional facilities are provided to assist in determining
deadlock occurrences.
I created
On Sat, 10 Jan 2015 19:39:19 -0800
Philip Guenther guent...@gmail.com wrote:
On Mon, 5 Jan 2015, Helg wrote:
The man page for LOCK(9) says that if the kernel option LOCKDEBUG is
enabled, additional facilities are provided to assist in determining
deadlock occurrences.
I created
results in warnings like:
implicit declaration of function '__mp_lock'
Adding includes for sys/mplock.h in the offending files resolves the problem
but this just doesn't seem right.
Does anyone have any suggestions?
--
Helg
)) == EWOULDBLOCK);
+
+ if (error) {
fuse_device_cleanup(dev, fbuf);
return (error);
}
--
Helg
This patch forces fuse to mount a client filesystem using the realpath
when a relative path is specified for the mount point. Without this, to
unmount a filesystem you need to change directory to the same folder
you where in when you mounted it.
--
Helg xx...@msn.com
Index: fuse.c
implementation on Linux.
--
Helg xx...@msn.com
Index: fuse_vnops.c
===
RCS file: /cvs/src/sys/miscfs/fuse/fuse_vnops.c,v
retrieving revision 1.16
diff -u -p -r1.16 fuse_vnops.c
--- fuse_vnops.c18 Mar 2014 08:51:53 - 1.16
I've been doing some testing of fuse and discovered a small bug where it only
allows file names up to 254 characters due to not taking the NULL terminator
into consideration when allocating structures.
--
Helg xx...@msn.com
Index: dict.c
38 matches
Mail list logo
