| Commit message (Collapse) | Author | Age |
|
|
|
|
|
| |
This is what the Linux version does, and it fixes a
timeout under FreeBSD when the kernel sends a FUSE_DESTROY
request that is never answered.
|
| |
|
| |
|
|
|
|
|
|
| |
mount_bsd.c is only used when compiling for *BSD, and FreeBSD
is the only BSD that supports FUSE. So there really is no need
to check if this file is compiled under FreeBSD.
|
| |
|
| |
|
|
|
|
|
|
| |
-oallow_root is handled in userspace, and requires passing -oallow_other
to the kernel. This patch should make the code easier to understand and
avoid the confusion that gave rise to issue #86.
|
|
|
|
|
|
|
|
|
|
| |
Eventually, this setting should be negotiated in the filesystem's init()
handler (like e.g. max_write). However, this requires corresponding
changes in the FUSE kernel module. In preparation for this (and to allow
a transition period) we already allow (and require) filesystems to set
the value in the init() handler in addition to the mount option.
The end-goal is tracked in issue #91.
|
|
|
|
|
|
|
|
|
| |
Both the BSD and Linux implementation actually accept mostly the same
FUSE-specific mount options. Up to now, the BSD help function appended
the output of ``mount_fusefs --help``, but looking at
http://www.unix.com/man-page/freebsd/8/mount_fusefs/ this is likely more
confusing than helpful (since the user is not actually invoking
mount_fusefs directly, most of the options don't make sense).
|
|
|
|
|
|
|
| |
We now only list options that are potentially useful for an
end-user (and unlikely to accidentally break a file system). The full
list of FUSE options has been moved to the documentation of the
fuse_new() and fuse_session_new() functions.
|
|
|
|
|
| |
This brings the default behavior in-line with that of the
regular `mount` command.
|
|
|
|
| |
This was only relevant for 2.4 kernels. Fixes #92.
|
|
|
|
|
| |
We also accept a number of mount options that are common to
all file systems (nosuid, nodev, ro, etc).
|
|
|
|
|
| |
This should make more clear what file contains code for what
purpose.
|
|
|
|
| |
Also, do not include "General options" in usage message.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The only struct fuse_chan that's accessible to the user application is
the "master" channel that is returned by fuse_mount and stored in struct
fuse_session.
When using the multi-threaded main loop with the "clone_fd" option, each
worker thread gets its own struct fuse_chan. However, none of these are
available to the user application, nor do they hold references to struct
fuse_session (the pointer is always null).
Therefore, any presence of struct fuse_chan can be removed
without loss of functionality by relying on struct fuse_session instead.
This reduces the number of API functions and removes a potential source
of confusion (since the new API no longer looks as if it might be
possible to add multiple channels to one session, or to share one
channel between multiple sessions).
Fixes issue #17.
|
| |
|
|
|
|
|
| |
This function was for backwards compatibility in FUSE 2.x, and
is no longer exposed by FUSE 3.
|
|
|
|
|
|
| |
Applied (whitespace-cleanup) to each file. Having whitespace changes
in the VCS is ugly, but it ensures that in the future committers
can run this function to *avoid* commiting any whitespace.
|
| |
|
|
|
|
| |
add AC_SYS_LARGEFILE to your configure.ac instead.
|
|
|
|
|
|
|
|
|
|
|
|
| |
- fuse_kern_unmount closes handle (e.g. 19)
- a thread in my process opens a file - the OS assigns newly freed
handle (i.e. 19)
- fuse_kern_chan_destroy closes the same handle (i.e. 19)
- a thread in my process opens another file - the OS assigns newly
freed handle (i.e. 19)
- * MAYHEM *
Reported by Dan Greenfield
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
forced unmount
|
|
|
|
| |
sensible way
|
| |
|
| |
|
| |
|
|
|
|
| |
Cf. lib/mount.c rev. 1.43.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|