It is sometimes helpful to know which process accesses
the filesystem.

Relates-to: https://github.com/hanwen/go-fuse/issues/478
Change-Id: Ie435d093f03a32c02f02b45df880a207c5d7cad1

Change-Id: I8f05010f64edaf1d41fdfca31ee4ae3079cd0ae3

As of commit 4f621f9a, we don't
support older versions

Change-Id: I9f05010f64edaf1d41fdfca31ee4ae3079cd0ae3

Change-Id: Ib094e7e55f922780408223626d88388d2cc5f8b6

Use UtimesNanoAt with AT_SYMLINK_NOFOLLOW. Add
PosixTest/SetattrSymlink to test this.

Change-Id: Ia3a00ad75afd1ba255965025f63fd047662885ec

posix_fallocate(2) returns error directly without setting errno[1]

[1]: https://man.freebsd.org/cgi/man.cgi?query=posix_fallocate&sektion=2

Change-Id: I90ac60ecab6f8814a579cc96d11d4d6660408e88

This test case is going to test whether the file lock works well on the
system. It firstly adds a lock and then get the lock through syscalls.
It uses F_OFD_GETLK command of fcntl(2) to get the lock info on an
opened file description[1], which is not defined on the FreeBSD. This
commit seperate the process of getting the information of lock for
different OSes, and mimic the behaviour of F_OFD_GETLK on FreeBSD.

[1]: https://www.gnu.org/software/libc/manual/html_node/Open-File-Description-Locks.html

Change-Id: I8abae0e7040fc667143eea028731e341be9b1baf

Fails to compile.
Example: https://github.com/hanwen/go-fuse/actions/runs/8909081785/job/24465823082

	Run GOMAXPROCS="1" ./all.bash
	+ go build ./...
	go: downloading golang.org/x/sys v0.0.0-20220520151302-bc2c85ada10a
	Error: fs/api.go:237:2: //go:build comment without // +build comment
	Error: fs/api.go:237:2: //go:build comment without // +build comment
	Error: Process completed with exit code 1.

Change-Id: I2e396906d9cf9fa2248b04f3963b1b2d32b6fd57

Calling Serve() multiple times leads to a panic on unmount and fun
debugging sessions ( https://github.com/hanwen/go-fuse/issues/512 ).
Catch it early.

Change-Id: I3c490448fa3b8407a6db1bd8ad94b8a4e1a93828

Per default, only 1000 FUSE mounts are allowed, then you get
> /usr/bin/fusermount3: too many FUSE filesystems mounted; mount_max=N can be set in /etc/fuse.conf

Let's stay well below 1000 as there may be other (unrelated)
FUSE mounts also occupying slots.

Change-Id: I2e2e094a88236ff803abba3722395c29207c8571

Change-Id: Iffa5314fbe171d182a4bdef42e0ab4781cc1d221

Prefer x/sys/unix over syscall package, which supports FreeBSD.

Change-Id: Ifd3a0fd6d2b90369a6e1e74d92606a655815a6a4

Change-Id: Ib1e1e1054db73df031e4be958206fc94bbea1236

test

Change-Id: Idcb3ee99c1afdde410e41e3a67c29c3143f602c3

Change-Id: Ifb01913d17650e0fa729888f64cd2fe2017dfe1f

Change-Id: I214834639a835b61db2fc0d283ffabb948535ff5

Change-Id: I8ff8e8dc9431b5af52e3ca8e78f0da73cead9008

Change-Id: Ibc41b9efc62f89359e712def53b1cfc1dd4c24fc

Both FreeBSD and Darwin must use a single reader to access the FUSE device.

Change-Id: I51c467bb0b8e1fda871665d033dd89d11fbe961c

fuse: merge attr definition of Darwin and FreeBSD

Change-Id: I7229229aed8afad74089bc2ce7eff0b86bd2ccd0

Change-Id: I7caa793f1b7a2c3601094ca46e1a3812e763e813

Change-Id: I76715678a305ebe981ba20392965ff5c011b883e

Change-Id: I2b80c97a8b7bd4e93085ba6fe4a0bf2a852db78e

Change-Id: I694fa828c6f71941412afbb46535eb40dbecb4b2

Thanks to https://github.com/likeazir for spotting this

Change-Id: I0952482886cfadb23c723d89a64fd4ced1b57c92

This avoids spurious error messages when unmounting a file system
directly after closing a file.

Fixes #505

Change-Id: I3a6a6ada0b5e5abe95a1d7965a48ddb46664310a

Commit 1aa7b7b2 ("fs: document known deadlocks") describes a deadlock
scenario where inheriting file descriptors triggers a spurious close
during subprocess setup, leading to deadlock.

This exact scenario actually happens when setting up the FUSE mount
using fusermount: the fusermount process inherits one half of a socket
pair, which is used to pass back the opened /dev/fuse file.  After the
mount is successful, we open a file in the FUSE mount for the poll
hack. This means that in parallel scenarios, we may use fd 3 as the
poll hack, while also calling fusermount with inherited file
descriptors.

Solve this by grabbing fd 3 during initialization.

This is not completely foolproof, as FD 0, 1 and 2 could be closed
(and then reused) after initialization finished, but this should be
uncommon as 0, 1 and 2 are standard input/output/error.

Doing it during the init phase means that we prevent deadlock for all
users that inherit single file descriptors.

Change-Id: If5ac7c941f0ee2e13ca657c31d056a676eed3fde

On amd64, syscall.O_LARGEFILE is 0x0, making it be ignored as a
key. However, the kernel always passes 0x8000 to the FUSE server for
the OPEN call.

The previous behavior causes crashes on 386, because the flagname is
added twice.

Change-Id: Ibabcdfef4d90e4fa4d02963d45a4d4cf2cba1ea2

make mount procedure cleaner by using standard library
to parse socker control message

Change-Id: Ic52f5a0e2ddda40e680e341e35fb9b4158ba3324

Tested on MacOS 14.2 (macfuse 4.5.0) and Ubuntu 20.04.2 (Linux 5.15.0)

Change-Id: I3f4f92c2d2aa3f4fc3696b661fa3cb0e3b43282b

Change-Id: I43f09613acd119daefe64350a46f79d58b2e4b6a

MacOS flags list retrieved from latest source version of MACFUSE library https://github.com/macfuse/library/blob/eee4f806272fcfba3c8ee662647068f8e3abab72/include/fuse_common.h

Tested on MacOS 14.2 (macfuse 4.5.0) and Alpine 3.18 in Docker (Linux 6.4)

Change-Id: Ia8a00aa915f37553d5c89612eeced816dc8fc997

`CAP_SETXATTR_EXT,CAP_INIT_EXT,CAP_INIT_RESERVED` opcodes conflicts with
osxfuse `CAP_CASE_INSENSITIVE,CAP_VOL_RENAME,CAP_XTIMES` opcodes,
that's causing panic, so it should be moved into linux specific build.

Change-Id: I0916ea0bd2c169a0aa1f654ef015799fa0e5084e

Change-Id: I1e10f22dc13207277af45cbbc2ac6740c9d4e36e

As part of the fork/exec sequence, file descriptors that should be
inherited are remapped with dup3() in the chld process. This causes
implicit file close operations. If the file descriptors are backed by
FUSE, this leads to FLUSH operations. If parallelism is limited with
GOMAXPROCS, this can cause a deadlock, as there will not be threads
left to service the FLUSH opcodes.

Fixes #489

Change-Id: I81bf4ab0624495aabb5bb9ec42a55c6f23340beb

This avoids one allocation under lock (calling sync.Pool.Put converts to
interface{})

Change-Id: Icfe155e34300dca398cea99b73bc5e10fd362ae3

The man page for lseek(2) says that the filesystem should
return an ENXIO when the offset is greater than the file
size on either SEEK_DATA or SEEK_HOLE or if the offset is
set to the end of the file with SEEK_DATA (where there is
an implicit hole). Adding these checks to the current Lseek
implementation.

Change-Id: I8db0913a9e37209e1681ffd11a9afb7f39810132

Change-Id: I4c61fa0f522fa07d0c02d8c7261a6c82ab6756a8

Change-Id: Id9812b765e6bdf06f92c2723d03112dca99faa36

Change-Id: Ia1e8e20f5646a0958f4ede5cf20f565c63f0bb7f