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

This adds opcodes and capabilities from this week's upstream kernel.

As of commit 53db28933 ("fuse: extend init flags"), the init message
has been extended to 104 bytes, with more flags added in a flags2
field.

Prepare for this by allowing _OP_INIT to have short reads.

Tested on Fedora 38 (Linux 6.4.14) and Fedora 34 (Linux 5.11)

Change-Id: I366ecda9e23f1a329134677075ee839674ff4c57

Change-Id: Icfae201b99d75b308ad5c4f3c96a0f5800127f62

Change-Id: I123f731802663adc2603d9bc34f5e376b6607fe5

Fixes an issue that the init() func in splice.go panics if
/dev is not yet mounted.

This allows supporting go-based init binaries which set up all the
filesystems on the machine, including both /dev as well as
FUSE-mounted dirs.

Change-Id: I74dab18effe4df410689ae7a2ef43670fcab7bd8

This allows for specializing the debug output.

Change-Id: Id6a24fd6207253af3f32ca0f7ed51db3db31ced4

Keep children in a slice of {name,*Inode} tuples, separately indexed
by a string map.

This ensures that we can return the children in insertion order. This
fixes #476 and #391, and opens the road to NFS-compatible readdir
cookies.

Change-Id: I79b3483f4b12e67b63543da1294f725029a9139a

Encapsulates the handling the children map, in preparation of changing
the representation. It also reduces repetition for handling the
parents field and changeCounter

Change-Id: Ic741a376c6261dab606ed0705cdd130e70c8b69e

As evidenced by the test failures that are reported, the
`Optional` may change value between mounts. Ignore it
in the comparison.

 --- FAIL: TestDirectMount (0.14s)
    mount_linux_test.go:173: DirectMount effective mount options mismatch:
        DirectMount: mountinfo.Info{ID:0, Parent:0, Major:0, Minor:0, Root:"", Mountpoint:"", Options:"rw,nosuid,nodev,relatime", Optional:"shared:417", FSType:"fuse./tmp/go-build3776165", Source:"a,b", VFSOptions:"rw,user_id=1000,group_id=1000,max_read=131072"}
        fusermount:  mountinfo.Info{ID:0, Parent:0, Major:0, Minor:0, Root:"", Mountpoint:"", Options:"rw,nosuid,nodev,relatime", Optional:"shared:373", FSType:"fuse./tmp/go-build3776165", Source:"a,b", VFSOptions:"rw,user_id=1000,group_id=1000,max_read=131072"}

Fixes https://github.com/hanwen/go-fuse/issues/481

Change-Id: Ie8105cf4bec7e7f461267217860cbf36e47ed329

flagString(flags, "default") should return default only if flags == 0.

Noticed by Han-Wen: https://review.gerrithub.io/c/hanwen/go-fuse/+/555490/comment/9cbd50ed_d836c29c/

Without the fix added test fails as

    --- FAIL: TestFlagStringDefault (0.00s)
        print_test.go:48: flagString(8, "X") -> got "X,0x8" ;  want "0x8"

Change-Id: I5b9432741e30948d490b276c097fbcfe45ecd936

This helps to compare fuse logs of e.g. different test runs. For example
below are two INIT messages with the same flags, but formatted, before
hereby patch, differently:

     rx 2: INIT n0 {7.37 Ra 131072 EXPORT_SUPPORT,SPLICE_READ,AUTO_INVAL_DATA,ASYNC_DIO,WRITEBACK_CACHE,BIG_WRITES,NO_OPEN_SUPPORT,PARALLEL_DIROPS,POSIX_ACL,EXPLICIT_INVAL_DATA,NO_OPENDIR_SUPPORT,ASYNC_READ,DONT_MASK,SPLICE_MOVE,IOCTL_DIR,READDIRPLUS,READDIRPLUS_AUTO,HANDLE_KILLPRIV,POSIX_LOCKS,ATOMIC_O_TRUNC,SPLICE_WRITE,FLOCK_LOCKS,ABORT_ERROR,MAX_PAGES,CACHE_SYMLINKS,0x70000000} "\x03\x00\x00\x00\x00\x00\x00\x00"... 48b

     rx 2: INIT n0 {7.37 Ra 131072 EXPORT_SUPPORT,SPLICE_READ,AUTO_INVAL_DATA,ASYNC_DIO,WRITEBACK_CACHE,BIG_WRITES,NO_OPEN_SUPPORT,PARALLEL_DIROPS,POSIX_ACL,EXPLICIT_INVAL_DATA,ASYNC_READ,DONT_MASK,SPLICE_MOVE,IOCTL_DIR,READDIRPLUS,READDIRPLUS_AUTO,HANDLE_KILLPRIV,NO_OPENDIR_SUPPORT,POSIX_LOCKS,ATOMIC_O_TRUNC,SPLICE_WRITE,FLOCK_LOCKS,ABORT_ERROR,MAX_PAGES,CACHE_SYMLINKS,0x70000000} "\x03\x00\x00\x00\x00\x00\x00\x00"... 48b

which leads to corresponding lines to be present in the diff and
requires human attention to verify that the messages are really the
same.

After this patch above INIT always formats as

     rx 2: INIT n0 {7.37 Ra 131072 ASYNC_READ,POSIX_LOCKS,ATOMIC_O_TRUNC,EXPORT_SUPPORT,BIG_WRITES,DONT_MASK,SPLICE_WRITE,SPLICE_MOVE,SPLICE_READ,FLOCK_LOCKS,IOCTL_DIR,AUTO_INVAL_DATA,READDIRPLUS,READDIRPLUS_AUTO,ASYNC_DIO,WRITEBACK_CACHE,NO_OPEN_SUPPORT,PARALLEL_DIROPS,HANDLE_KILLPRIV,POSIX_ACL,ABORT_ERROR,MAX_PAGES,CACHE_SYMLINKS,NO_OPENDIR_SUPPORT,EXPLICIT_INVAL_DATA,0x70000000} "\x03\x00\x00\x00\x00\x00\x00\x00"... 48b

and the diff log does not unnecessarily distract attention to it.

flagString is used for many messages, this fix should benefit all of
them.

Change-Id: Id4bdab9dd90552313ede41a3b9a6c337588e4b3e

The RELEASE opcode is asynchronous, so the next open() call may
execute before the RELEASE for the preceding one has completed. In
case of GOMAXPROCS=1, this happens often.

Increase the limit to 15 to reduce the chance of this causing a test
failure. The test runs 100 times, so this should still catch logic
errors with deallocating file handles.

Fixes #477.

Change-Id: I12dbd96b2a6082e0f4a386d35983e6efcc596aef

This test tries to create many files with random names and then asserts
that readdir returns so many files that it created. But the test
had a bug in that two random file names could be the same
name but accounted twice. This leads to assertion in the end that the
number of direntries read via readdir is not as expected.

Here is how two random names could turn out to be the same:

name 1: "file3" + "0" generated by randomLengthString
name 2: "file30" + "" generated by randomLengthString

-> Fix it by constructing random names guaranteed different.

Fixes: https://github.com/hanwen/go-fuse/issues/472
Change-Id: I776866bd728479da7324878d41dc71e504efd229

We already had this on Travis CI ( ffb96eff )
but lost it on the migration to Github Actions.

Relates-to: https://github.com/hanwen/go-fuse/issues/473
Change-Id: I1c987fe565227f707d50ea440929f9915a1e86e3

Change-Id: Ie0208ec43f50910201b8ff97f639ad55fbd319a3

In 2019 TestOpenKeepCache was first disabled in ce2558b4 (fuse/test:
disable TestFopenKeepCache) and then reenabled in 904ef0cc (fuse/test:
Fix TestFopenKeepCache). The latter patch hoped to fix this test

    - by disabling CAP_AUTO_INVAL_DATA via ExplicitDataCacheControl. This
      should stop kernel from dropping data cache on mtime change;
    - by using the same size for before and after states. This avoid hitting
      cache being dropped when kernel sees file size being changed.

In other words it took actions so that the data cache is not
unexpectedly dropped by the kernel and the test does not fail with
seeing different content after file reopen.

However the test also wants to verify that updated data can be seen
after cache invalidation and here it was not exactly correct: the test
requested full control over the data cache via ExplicitDataCacheControl
mount option, but was explicitly invalidating only file attributes
via pathfs.EntryNotify _without_ invalidating the data cache.

This way the test was actually working before Linux 5.2, because those
older kernels never negotiate CAP_EXPLICIT_INVAL_DATA(*), but starting
from Linux 5.2 CAP_EXPLICIT_INVAL_DATA started to be negotiated, and so
the kernel was dropping only metadata without invalidating data cache on
EntryNotify. This started to lead to the following test failures:

    --- FAIL: TestFopenKeepCache (0.13s)
        cache_test.go:153: ReadFile: got "before" after notify, want "afterX"

@hanwen explains in https://github.com/hanwen/go-fuse/issues/473#issuecomment-1585617107

    It tries to invalidate the file content by issuing an ENTRY_NOTIFY. This
    leads to different mtime returned, but in the init phase, we don´t
    return AUTO_INVAL_DATA, because setupCacheTest explicitly disables it.

    === RUN   TestFopenKeepCache
    12:47:49.958227 callFusermount: executing ["/usr/bin/fusermount3" "/tmp/TestFopenKeepCache1094589261/001/mnt" "-o" "subtype=pathfs.pathInode,max_read=131072"]
    12:47:49.967664 rx 2: INIT n0 {7.38 Ra 131072 FLOCK_LOCKS,IOCTL_DIR,READDIRPLUS,READDIRPLUS_AUTO,PARALLEL_DIROPS,HANDLE_KILLPRIV,ASYNC_READ,BIG_WRITES,SPLICE_WRITE,SPLICE_MOVE,WRITEBACK_CACHE,NO_OPEN_SUPPORT,POSIX_ACL,POSIX_LOCKS,EXPORT_SUPPORT,AUTO_INVAL_DATA,ASYNC_DIO,MAX_PAGES,CACHE_SYMLINKS,NO_OPENDIR_SUPPORT,DONT_MASK,SPLICE_READ,ABORT_ERROR,EXPLICIT_INVAL_DATA,ATOMIC_O_TRUNC,0x70000000} "\a\x00\x00\x00\x00\x00\x00\x00"... 48b
    12:47:49.967708 tx 2:     OK, {7.28 Ra 131072 BIG_WRITES,NO_OPEN_SUPPORT,MAX_PAGES,EXPLICIT_INVAL_DATA,ASYNC_READ,READDIRPLUS,PARALLEL_DIROPS 0/0 Wr 131072 Tg 0 MaxPages 32}

-> Let's fix this.

As explained in 904ef0cc we do not want to reenable AUTO_INVAL_DATA
because then the kernel will start dropping data cache on mtime change
and the test will start to fail in its first part - where we want to
assert that the data stays the same until data cache is invalidated.

So let's change EntryNotify to FileNotify to explicitly invalidate data
cache when we want the file to read with new data.

Hopefully fixes: https://github.com/hanwen/go-fuse/issues/473

(*) see git.kernel.org/linus/ad2ba64dd489 and github.com/hanwen/go-fuse/pull/273

Change-Id: I4ff0f2bef61f0217601eee6d272f7e5563b272d2

Change-Id: I609fbb036913148e77f4350ec8d816373fe13d09

Change-Id: I7e9b530906c233f7fcdac434984b9051acb7dbb9

Go 1.20 was released in February - 4 months ago:

https://go.dev/doc/devel/release

Change-Id: Id24b29f3f7009d34b3ec082adf623dfc41431876

In https://github.com/hanwen/go-fuse/commit/90b055af4668fce08c961406c32c15bbd7953fe4 we adjusted go-fuse to support fusermount
string options with commas and backslash. But https://github.com/hanwen/go-fuse/commit/90b055af4668fce08c961406c32c15bbd7953fe4
only verified that commas and backslashs work with fusermount and
missed checking if they also work when using 'DirectMount'.

Initially this may not look problematic, because the option string escaping
with backslashs is only applied when mounting with fusermount and isn't
applied when directly mounting [1].

But https://github.com/hanwen/go-fuse/commit/90b055af4668fce08c961406c32c15bbd7953fe4 also dropped an explicit check for commas [2]
which would have been applied independently from whether 'DirectMount' is
set or not. In other words, the previous patch changed go-fuse to allow commas
and backslashs in option strings for 'DirectMount' or fusermount, but missed
checking if commas/backslashs actually works with 'DirectMount'.

This patch therefore amends 'TestDirectMount' to ensure commas and
backslashs work in the 'fsname' option when 'DirectMount' is used.

[1] https://github.com/hanwen/go-fuse/blob/90b055a/fuse/mount_linux.go#L107
[2] https://github.com/hanwen/go-fuse/blob/854d591/fuse/server.go#L188-L192

Change-Id: I78c612c55fb08be66713cd5234a8ffd468dd1349