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

- provides an optional way to set e.g. Ino and/or Gen for
  the root directory when calling fs.Mount()
- provides unit test cases
- partial fix for #399

Change-Id: If45a0ec3c0ea06c0419913e34b3415808f9349da

Allows to enable the DirectMount{,Strict} flag through the cli,
facilitating testing.

Change-Id: I46e273ea68e6a81b4e7873802bc3b1c7760f56f0

Commit

	17c7e2cd loopback: show original directory in "df"

added the FsName field to MountOptions, but looks like

	d31db957 fuse: allow setting the fsname (first column in df -T)

forgot that it exists. Use it now.

This will be important for DirectMount, as passing "fsname=xxx" to
the mount syscall causes the kernel to reject with EINVAL and this
message in dmesg:

	[132274.900267] fuse: Unknown parameter 'fsname'

Change-Id: Ic1233fe9306e2ce05f85189eecceecec2baa44b7

These were open-coded before. Pull them into the struct
initializer for somewhat clearer code.

I'm doing this now as I'm about to add another option.

Change-Id: Ie04cfc9fb1f4128b8faf5c85757d7263aa77e5a0

Do what fusermount does instead of hard-coding the strings.

Change-Id: Idf18f1c5cd17b7f9db8e15e8bc5173d0f6ca41db

Two variable were defined but never used in what looks like
a copy-paste error or something.

Fix that, which also makes the tests pass.

Change-Id: Iebf48583874977c518d888d9a80bc1f02e2a7f86

Reason for adding DirectMountStrict is making the DirectMount
functionality testable, though it may have value for the user
in some cases.

Add defaultRawFileSystem & loopback tests for DirectMount
and DirectMountStrict.

The tests fail right now due to bugs in DirectMount that will be fixed
shortly:

	go-fuse/fuse$ sudo /usr/local/go/bin/go test -run TestDirectMount
	[...]
	2022/12/28 20:19:21 mountDirect: calling syscall.Mount("", "/tmp/TestDirectMount3242971772", "fuse./tmp/go-build1215740", 0x0, "fd=7,rootmode=40000,user_id=0,group_id=0")
	2022/12/28 20:19:21 mount: failed to do direct mount: invalid argument
	[...]

Change-Id: Ibfa2fa141cb43e1f8c7319233c454a3e85fa435e

Change-Id: I1aff29b88edff004f2b1cf7c36831c1767608b0d

Kernel 4.20 allows writes & reads up to 1 MiB (before: 128 kiB)
via CAP_MAX_PAGES & MaxPages.

Instead of exposing MaxPages in the API, we follow what libfuse
does, and calculate MaxPages from MaxWrite (rounding up).

Contrary to what libfuse does, we also set max_read to the same
value as MaxWrite. This prevents reads getting larger than writes
due to the rounding-up for MaxPages, which is unexpected. This
also changes the default behavoir of go-fuse, which was 64 kiB
writes, but 128 kiB for reads. Now it is 128 kiB for both.

The tests are implemented in the fs package because it's
easier there. They also test MaxReadAhead.

Tested on Linux 4.19.0 and Linux 6.1.7 via all.bash,
and on 6.1.7 also via the gocryptfs test suite.

Supersedes https://github.com/hanwen/go-fuse/pull/347

Change-Id: I5a1d4ee91945155c367888da7a90814a24a9ee6e

When ReadDirPlus is enabled, the FUSE fs has to gather a lot of additional data for every file even if it won't be used (for example when the user is doing and 'ls' or a large glob). This can cause performance problems, so it should be possible to switch to the simple ReadDir behavior for file systems where this is a bottleneck.

Change-Id: I7f2e58fe6e728a408044ce789633423f6e527554

Change-Id: If4af8e09d1921242e36a415317d390154c5c2891

Change-Id: Icb2931139a6293abaaa95623a8e130dd6f8dab0b

There is a sync.Pool leak in server.go, which triggers in case of
multi-threaded loads.

Benchmarks:

env: Intel(R) Core(TM) i7-10700 CPU @ 2.90GHz (8core 16procs)
go test -bench="BenchmarkGoFuseRead" -benchmem

old:

2       10992 92501 ns/op 22671.71 MB/s 536981 B/op 196 allocs/op
4       19068 57959 ns/op 36183.44 MB/s 151877 B/op 170 allocs/op
8       27729 43796 ns/op 47884.39 MB/s 29068 B/op 162 allocs/op
16      28674 41403 ns/op 50651.65 MB/s 6704 B/op 160 allocs/op

fixed:

2       23667 46589 ns/op 45014.20 MB/s 5357 B/op 167 allocs/op
4       27753 42327 ns/op 49546.77 MB/s 4999 B/op 161 allocs/op
8       29648 40806 ns/op 51392.81 MB/s 4904 B/op 160 allocs/op
16      29389 40763 ns/op 51447.07 MB/s 4848 B/op 160 allocs/op

Change-Id: I062928203df5603ebca04c08c4d428d385f99c2c

The links pointed to a version of the docs from 2019.

Change-Id: I17a0739dbf23af015259ecb61493f304630548d7

Fixes rfjakob/gocryptfs#595 where we can't use gocryptfs -ro or gocryptfs -reverse on macOS because go-fuse tries to write to the read-only mountpoint during initial mount.

Fixes: #373
Change-Id: Ieadc0e074f4d803e88f9c21bb15b90eb9010afd8

OSXFUSE applies a 60-second timeout for file operations. This
is inconsistent with how FUSE works on Linux, where operations
last as long as the daemon is willing to let them run.

Change-Id: I6c042a3e785961a2c47c67e27d530bee5c50ce77

7.12 also allows usage of invalidation

Change-Id: I6e0480b7454187160f0b9f4b018386ba650048b7

These were deleted locally, but forgot to amend the commit.

Change-Id: I78c350aee09b6bb5d1a286514cae0c9a34d1396e

This library was created as a mechanism to overlay a writable checkout
for Git on top of Google's readonly SrcFS filesystem. This use case
has long disappeared, and the unionfs library appears unused
otherwise. Due to its reliance on timestamps and delays, it is very
susceptible to flakiness in tests.

Fixing this seems hard or maybe even impossible, so just remove the
library.

Change-Id: I6c594a724a0579b5c4c3aada76cd7013195fda94

Change-Id: I2b996ca3bfd1ea7e605e4dfd785cba2796340cd5

MKNOD returns an EntryOut that we can decode.

Before:

20:27:39.722507 rx 24914: MKNOD n1 {010644 (022), 0} ["pipe"] 5b
20:27:39.722546 tx 24914:     OK

After:

20: 32:39.156352 rx 38: MKNOD n1 {010644 (022), 0} ["pipe"] 5b
20: 32:39.156389 tx 38:     OK, {n3 g1 tE=1s tA=1s {M010644 SZ=0 L=1 1027:1027 B0*4096 i0:46906 A 1641756759.155157 M 1641756759.155157 C 1641756759.155157}}
Change-Id: If40e690219f20459466d7c8f9aa822c7186179dc

The readPool size was calculated from MaxWrite not taking
into account that the kernel fails all reads below 8 kiB.

Fix that by always using at least 8kiB.

Change-Id: I3bd9013be44b00bdc370bac00d00b4a106ec2d07