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

Before this patch no commas were allowed in any fusermount option string.
But it is in fact possible to use commas in fusermount options: we only
need to escape them [1].

Now go-fuse users can use commas in fusermount options.

Related libfuse commits are [1] and [2].

This patch also adds a test which ensures neither go-fuse nor fusermount
crash if we pass options with commas.

---

[1] https://github.com/libfuse/libfuse/commit/555d6b504308eac6b976321ce938ee4bec62c354
[2] https://github.com/libfuse/libfuse/commit/5c094ac0150ebfef6a2c9c2c9d1c545a90ff4e96

Change-Id: Iadf8283e630dc1fb884d047d8765eeaaca90eabd

Change-Id: I2aacf5775033dae03772d87b4a5c3f15bd961aff

Change-Id: Idf8f8f08849b279f1c8a346112d43e0eb44f9810

Change-Id: I48236bf879939537944e617baa620884e7601055

Change-Id: Ide68c48ffc2b8343884639835b958bf404739dbc

Change-Id: Ib86b9b98ce62783992ed233fe809f3552dc7bd99

A spurious blank line dropped the entire doc string.

Set Size in the Lookup example

Change-Id: Idefd113f7749e8aadfc4730e38b7444f36c0e419

Fixes this test failure:

2023/04/13 20:25:20 callFusermount: executing ["/usr/bin/fusermount3" "/tmp/TestDirectMount4166040800" "-o" "allow_other,subtype=/tmp/go-build1065896,max_read=131072"]
/usr/bin/fusermount3: option allow_other only allowed if 'user_allow_other' is set in /etc/fuse.conf

\--- FAIL: TestDirectMount (0.01s)
    mount_linux_test.go:117: fusermount exited with code 256

Change-Id: I4a2a2983dd422de9360b17068ac0d8a3947d453d

Change-Id: Ifb84efcb76615cc492c867afb9e1840a6977d402

Commit 265a3926 missed
adding max_read to the DirectMount path.

Add it, which fixes the TestDirectMount failures.

Change-Id: Ie934944d8f0a08fb65e2b6f675c8032f404d50df

Also test several max_write values, and different fs names.
And make the fail output easier to read.

Change-Id: Idbc9003554dfd7320890488f0b16cd5cfce1d6b4

Change-Id: I1d0537a1f50eb850c7741db1253189dfcf81711c

Change-Id: Iee1d90c83a1ff41dadbea07259e71fde7b0cfb22

Change-Id: Ieba742bdbe830fdc18f82986694e2cd4d7caf161

According to the lseek(2) manpage, seek(SEEK_HOLE) should behave as if
there is an implicit hole at the end of every file.

Add a test.

Fixes #417.

Change-Id: I169a803ea81e3c920b61edf8bb8b774870d042c5

Add a test.

Change-Id: I8620e59ce2fc7b19f595c5670839735243fcd1bf

Previously, if a DirStream.Next() call would return error, we would
return the buffered data as well as the errno code in the same
request.

This would confuse the kernel, who interprets this as an invalid
response, returning syscall.EIO to the caller.

To fix this, also buffer the errno as overflow entry in the fileEntry
struct. When we encounter an error, return thus far read entries with
success. The following read contains just the error.

For testing this properly, loopbackDirStream (which reads directory
contents) must also buffer error returns.

Change-Id: Ideb8ea6f540de9189a0f366efca0db2205e5dec3

Adds fuse.Options.EnableSymlinkCaching to enable cached
symlinks. Updates in GETATTR results do not trigger new READLINK
calls, so this breaks backward compatibility for file systems that
have auto-updating symlinks (e.g. a symlink pointing to the HEAD
revision of a remote git repository)

Change-Id: Ifcbcd75e

The logging makes it seems something is wrong when running the test.

Change-Id: I4e8ec5c72da555922ca7d20f0a34b9939b36fa9a

This avoids a deadlock on Darwin, because futimens calls
loopbackFile.Getattr again.

Fixes #419

Change-Id: Ia45a0ec3c0ea06c0419913e34b3415808f9349da

Change-Id: I9357f137487d1c958a95ed46db081b7775604b6b

Change-Id: Ifec1f504e014c3af9fe79943660831be0598a6d2

Change-Id: Ia0d7293d14bb4fdac9be913ba6bd92b836636070

Change-Id: I115ebce34aaf22767bb8b90b842927c133e30b65

This avoids that the result from concurrent directory reads (which
would return entries in different order) pollute kernel caches. Add a
test.

Fixes #391

Change-Id: I06a252bd

Change-Id: I144cb541

Change-Id: I1612f912dd6b113e7776b13c40f9a41038a3fd53

Signed-off-by: Alex Fishman <alex@fuse-t.org>
Change-Id: I82de5e2dd0340da4e05e4ccf1bbd162dff33b656

Darwin amd64 uses uint16 for Stat_t.mode
Signed-off-by: Alex Fishman <alex@fuse-t.org>
Change-Id: I82de5e2dd0340da4e05e4ccf1bbd162dff33b611

Change-Id: I3a67066a6660481bdab81278a91027755973b496