| Age | Commit message (Collapse) | Author | Lines |
|---|
|
This should simplify the code a lot. It also corrects a bug in
that the (former) add_default_fsname() function actually set
the -osubtype option.
|
|
|
|
|
|
This may not make sense for all options, but it's good practice.
|
|
|
|
|
|
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.
|
|
Instead of using command line options to modify struct fuse_conn_info
before and after calling the init() handler, we now give the file system
explicit control over this.
|
|
This option really affects the behavior of the session loop, not the
low-level interface. Therefore, it does not belong in the fuse_session
object.
|
|
There's now a way to inhibit the "usage" line (which actually got lost
in commit 225c12aebf2d), which makes it easier for simply file-systems
to generate good-looking --help output.
|
|
|
|
The current behavior makes it difficult to add help for
additional options. With the change, this becomes a lot easier.
|
|
|
|
Help and version messages can be generated using the new
fuse_lowlevel_help(), fuse_lowlevel_version(), fuse_mount_help(), and
fuse_mount_version() functions.
The fuse_parse_cmdline() function has been made more powerful
to do this automatically, and is now explicitly intended only
for low-level API users.
This is a code simplication patch. We don't have to parse for --help and
--version in quite as many places, and we no longer have a low-level
initialization function be responsible for the (super-high level) task
of printing a program usage message.
In the high-level API, we can now handle the command line parsing
earlier and avoid running other initialization code if we're just going
to abort later on.
|
|
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.
|
|
|
|
|
|
Mounting a FUSE file system remotely using SSH in combination with
pseudo-terminal allocation (-t), results in "Transport endpoint is
not connected" errors when trying to access the file system contents.
For example:
# ssh -t root@localhost "cmsfs-fuse /dev/disk/by-path/ccw-0.0.0190 /CMSFS"
Connection to localhost closed.
# ls /CMSFS
ls: cannot access '/CMSFS': Transport endpoint is not connected
The cmsfs-fuse main program (which can also be any other FUSE file
system) calls into the fuse_main() libfuse library function.
The fuse_main() function later calls fuse_daemonize() to fork the
daemon process to handle the FUSE file system I/O.
The fuse_daemonize() function calls fork() as usual. The child
proceeds with setsid() and then redirecting its file descriptors
to /dev/null etc. The parent process, simply exits.
The child's functions and the parent's exit creates a subtle race.
This is seen with an SSH connection. The SSH command above calls
cmsfs-fuse on an allocated pseudo-terminal device (-t option).
If the parent exits, SSH receives the command completion and closes
the connection, that means, it closes the master side of the
pseudo-terminal. This causes a HUP signal being sent to the process
group on the pseudo-terminal. At this point in time, the child might
not have completed the setsid() call and, hence, becomes terminated.
Note that fuse daemon sets up its signal handlers after fuse_daemonize()
has completed.
Even if the child has the chance to disassociate from its parent process
group to become it's own process group with setsid(), the child still
has the pseudo-terminal opened as stdin, stdout, and stderr. So the
pseudo-terminal still behave as controlling terminal and might cause a
SIGHUP at closing the the master side.
To solve the problem, the parent has to wait until the child (the fuse
daemon process) has completed its processing, that means, has become
its own process group with setsid() and closed any file descriptors
pointing to the pseudo-terminal.
Closes: #27
Reported-by: Ofer Baruch <oferba@il.ibm.com>
Reviewed-by: Gerald Schaefer <gerald.schaefer@de.ibm.com>
Signed-off-by: Hendrik Brueckner <brueckner@linux.vnet.ibm.com>
|
|
|
|
|
|
Returns the full PACKAGE_VERSION string, per autoconf
|
|
New functions: fuse_chan_get(), fuse_chan_put(). Removed function:
fuse_chan_destroy().
|
|
|
|
There's actually just one type of channel and session, so we don't need the
generic callback functions.
|
|
Replace fuse_session_next_chan() with fuse_session_chan(), as multiple
channels per session were never actually supported and probably never will.
|
|
- 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
|
|
|
|
for consistency.
Reported by Vladimir Rutsky
|
|
|
|
|
|
|
|
daemon() is a BSD-ism. Although it is available on many platforms
it is not a standard function. Some platforms (e.g. MacOSX) deprecated
it.
It is safer just to use fork() function that is a part of POSIX.
|
|
|
|
The bulk of it is just about adding ifdef __NetBSD__ where there is
already an ifdef __FreeBSD__
Add a arch=netbsd to deal with NetBSD specifics. I suggests that
arch=bsd could be renamed to arch=freebsd
NetBSD specific linking with -lperfuse
NetBSD patches to lib/mount.c. It turned to be less itrusive to patch
mount;c than mount_bsd.c. I suggest mount_bsd.c could be renamed to
mount_freebsd.c
Patch from Emmanuel Dreyfus
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
