Change-Id: I87f5ff47daeb64412ff877038619d6cdf5e6ec92

Document MvChild failure condition.

Change-Id: I928335eb79c73bdedb14c9f7544c3b15e3862af8

Change-Id: I15d31de59b4c34caff132bdc7d09ad520d0e68cb

Change-Id: I3bce0eee02e0f8d1a2d02c4a4f065bb023179ab1

Any subsequent attempt to remove the mountdir will fail if the unmount
does not succeed.

Use syscall.Rmdir rather than os.Remove. We know the mount point is a
directory, and Go's cleverness can only complicate matters here.

Change-Id: I62cfad63f34af17b78c3184884a2972673f631a3

Change-Id: I4d77ac9194ca9caedf7b0418386e22ae57b90b9b

In TestBridgeReaddirPlusVirtualEntries we test that "." comes first,
and then "..". This ordering is not reliable. On
4.19.67-2rodete2-amd64, I see ".." before "."

Adapt the test to accept either ordering.

Change-Id: Ifc003dca6c2b19d9df3045ac30569ee27f78fc52

Change-Id: I59a1f187ff4c88bcefdb1e70c6461ca4b2a79c3b

After running the test suite, `df` used to report this:

  df: /tmp/TestReaddirTypeFixup090721515: Transport endpoint is not connected

To catch problems like this earlier, testMount() now reports failures to umount
cleanly, and catches the problem with TestReaddirTypeFixup:

  $ go test ./fs -run TestReaddirTypeFixup
  [...]
      mem_test.go:37: testMount: Unmount failed: /usr/bin/fusermount: failed to unmount /tmp/TestReaddirTypeFixup175482633: Device or resource busy

TestReaddirTypeFixup was missing ds.Close(), which was also added,
tests pass now and don't leave broken mounts behind.

Change-Id: Ib5d96c8531b11080cf8da526b917446388537956

Tests that openat(2) works as expected when the parent
directory is renamed (it does).

Originally written to get a FUSE log about what happens
when userspace calls openat, but it might make sense to
just keep it as a test.

Change-Id: I3fac815a7c0f713b4f859f6876d60380df9bc953

I have suddenly seen TestTypeChange hang forever, waiting for the
FORGET that never arrives. The first concern was that the assumption
that the FORGET always follows the delete was wrong. Checking the
kernel source code, the FORGET should really, actually always follow
the delete.

Looking more closely on the debug trace showed this:

        LOOKUP i1 [".Trash-1026"] 12b
             OK, {i1234 g0 tE=0s tA=0s {M0100644 SZ=0 L=0 0:0 B0*4096 i0:1234 A 0.000000 M 0.000000 C 0.000000}}

This is the desktop environment looking for the trash folder.
And because the test is stupid, it returned the same dummy
inode i1234. This means the kernel had one extra reference
to this inode and, of course, did not send a FORGET when
"file" was deleted.

I made testTypeChangeIno only react to expected file names
now, and added a log output should we wait more than ~5
seconds for the FORGET. The log message then repeats indefinitely
every 5 seconds.

        ~/go/src/github.com/hanwen/go-fuse/fs$ go test -v -run TestTypeChange
        === RUN   TestTypeChange
        20:50:18.491584 rx 2: INIT i0 {7.31 Ra 0x20000 CACHE_SYMLINKS,POSIX_LOCKS,SPLICE_MOVE,SPLICE_READ,READDIRPLUS,READDIRPLUS_AUTO,PARALLEL_DIROPS,ABORT_ERROR,EXPLICIT_INVAL_DATA,ASYNC_READ,EXPORT_SUPPORT,DONT_MASK,NO_OPENDIR_SUPPORT,SPLICE_WRITE,FLOCK_LOCKS,AUTO_INVAL_DATA,HANDLE_KILLPRIV,MAX_PAGES,POSIX_ACL,ATOMIC_O_TRUNC,BIG_WRITES,IOCTL_DIR,ASYNC_DIO,WRITEBACK_CACHE,NO_OPEN_SUPPORT}
        20:50:18.491728 tx 2:     OK, {7.28 Ra 0x20000 NO_OPEN_SUPPORT,BIG_WRITES,PARALLEL_DIROPS,READDIRPLUS,ASYNC_READ,AUTO_INVAL_DATA 0/0 Wr 0x10000 Tg 0x0}
        20:50:18.491857 rx 4: ACCESS i1 {u=1026 g=1026 r}
        20:50:18.491873 tx 4:     OK
        20:50:18.492028 rx 6: LOOKUP i1 [".go-fuse-epoll-hack"] 20b
        20:50:18.492110 tx 6:     2=no such file or directory, {i0 g0 tE=0s tA=0s {M00 SZ=0 L=0 0:0 B0*0 i0:0 A 0.000000 M 0.000000 C 0.000000}}
        20:50:18.492147 rx 8: CREATE i1 {0100100 [TRUNC,WRONLY,CREAT,0x8000] (00)} [".go-fuse-epoll-hack"] 20b
        20:50:18.492207 tx 8:     OK, {i18446744073709551615 g0 {M0100644 SZ=0 L=1 0:0 B0*0 i0:18446744073709551615 A 0.000000 M 0.000000 C 0.000000} &{18446744073709551615 0 0}}
        20:50:18.492291 rx 10: LOOKUP i1 [".Trash"] 7b
        20:50:18.492340 tx 10:     OK, {i1234 g0 tE=0s tA=0s {M0100644 SZ=0 L=0 0:0 B0*4096 i0:1234 A 0.000000 M 0.000000 C 0.000000}}
        20:50:18.492354 rx 12: POLL i18446744073709551615
        20:50:18.492359 tx 12:     38=function not implemented
        20:50:18.492370 rx 14: LOOKUP i1 [".go-fuse-epoll-hack"] 20b
        20:50:18.492378 tx 14:     2=no such file or directory, {i0 g0 tE=0s tA=0s {M00 SZ=0 L=0 0:0 B0*0 i0:0 A 0.000000 M 0.000000 C 0.000000}}
        20:50:18.492389 rx 16: GETATTR i1234 {Fh 0}
        20:50:18.492398 tx 16:     OK, {tA=0s {M0100644 SZ=0 L=0 0:0 B0*4096 i0:1234 A 0.000000 M 0.000000 C 0.000000}}
        20:50:18.492412 rx 18: FLUSH i18446744073709551615 {Fh 18446744073709551615}
        20:50:18.492417 tx 18:     5=input/output error
        20:50:18.492427 rx 20: LOOKUP i1 [".go-fuse-epoll-hack"] 20b
        20:50:18.492435 tx 20:     2=no such file or directory, {i0 g0 tE=0s tA=0s {M00 SZ=0 L=0 0:0 B0*0 i0:0 A 0.000000 M 0.000000 C 0.000000}}
        20:50:18.492450 rx 22: RELEASE i18446744073709551615 {Fh 18446744073709551615 WRONLY,0x8000  L0}
        20:50:18.492456 tx 22:     5=input/output error
        20:50:18.492469 rx 24: LOOKUP i1 ["file"] 5b
        20:50:18.492477 tx 24:     OK, {i1234 g0 tE=0s tA=0s {M0100644 SZ=0 L=0 0:0 B0*4096 i0:1234 A 0.000000 M 0.000000 C 0.000000}}
        20:50:18.492489 rx 26: LOOKUP i1 [".Trash-1026"] 12b
        20:50:18.492497 tx 26:     OK, {i1234 g0 tE=0s tA=0s {M0100644 SZ=0 L=0 0:0 B0*4096 i0:1234 A 0.000000 M 0.000000 C 0.000000}}
        20:50:18.492506 rx 28: GETATTR i1234 {Fh 0}
        20:50:18.492513 tx 28:     OK, {tA=0s {M0100644 SZ=0 L=0 0:0 B0*4096 i0:1234 A 0.000000 M 0.000000 C 0.000000}}
        20:50:18.492521 rx 30: GETATTR i1234 {Fh 0}
        20:50:18.492528 tx 30:     OK, {tA=0s {M0100644 SZ=0 L=0 0:0 B0*4096 i0:1234 A 0.000000 M 0.000000 C 0.000000}}
        20:50:18.492537 rx 32: LOOKUP i1 ["file"] 5b
        20:50:18.492545 tx 32:     OK, {i1234 g0 tE=0s tA=0s {M0100644 SZ=0 L=0 0:0 B0*4096 i0:1234 A 0.000000 M 0.000000 C 0.000000}}
        20:50:18.492555 rx 34: FORGET i18446744073709551615 {Nlookup=1}
        20:50:18.492575 rx 36: UNLINK i1 ["file"] 5b
        20:50:18.492588 tx 36:     OK
        20:50:18.492621 rx 38: LOOKUP i1 ["dir"] 4b
        [hangs here]

Change-Id: Ibee48faf09c5a8993dfc7bb75251551f699cd63e

Options.ServerCallbacks can set the callbacks used when not mounting
the filesystem.

Change-Id: I51bf875a816c23e587ec8b575110221bdfcdaffe

This provides more fidelity for reproducing file system behavior. Case
in point, it lets us rename a directory on top of an existing
directory

Fixes #55.

Change-Id: I82572aae32ee225b1629303c448a09f1066eb4ed

ListXAttr called with an empty buffer returns the current size of
the list but does not touch the buffer (see man 2 listxattr).

Fixes the xfstests generic/020 crash.
Fixes https://github.com/hanwen/go-fuse/issues/337 .

Add test
Co-authored-by: Han-Wen Nienhuys <hanwen@google.com>
Change-Id: I94c94bc56fdf506d2eb924b246336b787fa2976a

The tests sometimes hang in a way that "go test -timeout"
does not work anymore.

Example: https://travis-ci.org/hanwen/go-fuse/jobs/609260654

Use the external "timeout" command as backup, triggering
1 minute later.

Also, the test that seems to hang is "fs", run it alone
first in the hope of getting more info.

Add "set -e" so executing stops if the first step fails
( https://github.com/travis-ci/travis-ci/issues/1066 )

Also add "-failfast" to "go test" so the failures are
not buried in later output.

All failure modes are easier to analyze now in my opinion,
as you just have to scroll to the bottom to see what is
going on.

Examples:
* https://travis-ci.com/rfjakob/go-fuse/jobs/254766675
  TestStatFs failure due to non-deterministic test, stopped by -failfast)
* https://travis-ci.com/rfjakob/go-fuse/jobs/254766676
  Hang in TestParallelDiropsHang, stopped by -timeout, backtrace available
* https://travis-ci.com/rfjakob/go-fuse/jobs/254766677
  Hang somewhere in "go test ./...", killed by "timeout -k 10".
  No backtrace, unfortunately, but at least it took 6 minutes
  instead of 10.

Change-Id: I8069d22863c178b5c9c4d0c40f13dccfdfd0873d

When a inode is deleted and recreated, the inode number may
be reused, and it may appear that it has changed type.

A simple solution is to wait for the FORGET that *always*
follows the deletion. This is what this patch does.

Makes fsstress happy (tested with fsstress-loopback.bash from
gocryptfs, which is similar to xfstests generic/013).

Also fixes the test that was introduced in the last commit
(TestTypeChange).

fsstress-loopback.bash before:

    ~/go/src/github.com/rfjakob/gocryptfs/tests/stress_tests$ ./fsstress-loopback.bash
    Recompile go-fuse loopback
    Waiting for mount:  ok
    Starting fsstress loop
    1
        fsstress.1 seed = 1572931176
        fsstress.2 seed = 1572919573
        fsstress.3 seed = 1573005097
        rm
    rm: cannot remove '/var/tmp/fsstress-loopback.bash.qgK.mnt/fsstress.2/p4/d1XXXX': Is a directory
    rm: cannot remove '/var/tmp/fsstress-loopback.bash.qgK.mnt/fsstress.2/p6/d0/d44XXXXXXXXXXXX/d4cXXXX': Is a directory
    rm: cannot remove '/var/tmp/fsstress-loopback.bash.qgK.mnt/fsstress.3/p1/d11/d124/d12f/d154/d15a/d143/df1/d100/d135/d123/d3a': Is a directory
    rm: cannot remove '/var/tmp/fsstress-loopback.bash.qgK.mnt/fsstress.3/p1/d11/f22': Not a directory
    rm: cannot remove '/var/tmp/fsstress-loopback.bash.qgK.mnt/fsstress.3/p3/d0/d7e/d4b/d102/d157/d134/d12f/d14b/d17a/d130': Is a directory
    rm: cannot remove '/var/tmp/fsstress-loopback.bash.qgK.mnt/fsstress.3/p3/d0/d7e/d4b/d102/d157/d158/df2/ff5': Not a directory
    rm: cannot remove '/var/tmp/fsstress-loopback.bash.qgK.mnt/fsstress.3/p3/d0/d1c': Is a directory
    rm: cannot remove '/var/tmp/fsstress-loopback.bash.qgK.mnt/fsstress.3/p0/d0/d4': Is a directory
    rm: cannot remove '/var/tmp/fsstress-loopback.bash.qgK.mnt/fsstress.3/p2/d6/dfd/da6/df2/d124/dea/d100/d120/d131/d13e/d13b/d149/d13a/f9c': Not a directory
    rm: cannot remove '/var/tmp/fsstress-loopback.bash.qgK.mnt/fsstress.3/p2/d6/dfd/da6/df2/d124/dea/dd5/dfa/d127/d129/d14a/d117/d14c/d82': Is a directory
    ./fsstress-loopback.bash: line 1: kill: %1: no such job

After (with typechangeDebug = true):

    $ ./fsstress-loopback.bash
    Recompile go-fuse loopback
    Waiting for mount:  ok
    Starting fsstress loop
    1
        fsstress.1 seed = 1574198874
        fsstress.2 seed = 1574016238
    17:51:25.770396 Ino:13634604 typechange 0x8000 -> 0xa000, sleep=0s
    17:51:25.890382 Ino:13899580 typechange 0xa000 -> 0x8000, sleep=0s
    17:51:25.890400 Ino:13899580 typechange 0xa000 -> 0x8000, sleep=1µs
    17:51:25.890412 Ino:13899580 typechange 0xa000 -> 0x8000, sleep=1.41µs
        fsstress.3 seed = 1574847533
    17:51:27.472057 Ino:14158985 typechange 0x4000 -> 0x8000, sleep=0s
    17:51:27.472070 Ino:14158985 typechange 0x4000 -> 0x8000, sleep=1µs
    17:51:27.472304 Ino:14158985 typechange 0x8000 -> 0x4000, sleep=0s
    17:51:27.478628 Ino:14159000 typechange 0x8000 -> 0x4000, sleep=0s
    17:51:27.478640 Ino:14159000 typechange 0x8000 -> 0x4000, sleep=1µs
    17:51:27.478700 Ino:14159000 typechange 0x8000 -> 0x4000, sleep=1.051µs
    17:51:27.478747 Ino:14159000 typechange 0x8000 -> 0x4000, sleep=1.817µs
    17:51:27.478796 Ino:14159000 typechange 0x8000 -> 0x4000, sleep=3.18µs
    17:51:27.478840 Ino:14159000 typechange 0x8000 -> 0x4000, sleep=5.718µs
    17:51:27.478884 Ino:14159000 typechange 0x8000 -> 0x4000, sleep=8.396µs
    17:51:27.478976 Ino:14159000 typechange 0x8000 -> 0x4000, sleep=10.784µs
    17:51:27.479024 Ino:14159000 typechange 0x8000 -> 0x4000, sleep=13.017µs
    17:51:27.479067 Ino:14159000 typechange 0x8000 -> 0x4000, sleep=16.065µs
    17:51:27.479108 Ino:14159000 typechange 0x8000 -> 0x4000, sleep=19.767µs
    17:51:27.479145 Ino:14159000 typechange 0x8000 -> 0x4000, sleep=27.427µs
    17:51:27.479240 Ino:14159000 typechange 0x8000 -> 0x4000, sleep=36.272µs
    17:51:27.500756 Ino:14291431 typechange 0x4000 -> 0x8000, sleep=0s
    17:51:27.500770 Ino:14291431 typechange 0x4000 -> 0x8000, sleep=1µs
    17:51:27.500779 Ino:14291431 typechange 0x4000 -> 0x8000, sleep=1.873µs
    17:51:27.521194 Ino:14291506 typechange 0x4000 -> 0x8000, sleep=0s
    17:51:27.521207 Ino:14291506 typechange 0x4000 -> 0x8000, sleep=1µs
        rm
    2
        fsstress.1 seed = 1574600636
        fsstress.2 seed = 1574203490
    17:51:29.009666 Ino:12209562 typechange 0x4000 -> 0xa000, sleep=0s
    17:51:29.010068 Ino:12209562 typechange 0x4000 -> 0xa000, sleep=1µs
    17:51:29.010078 Ino:12209562 typechange 0x4000 -> 0xa000, sleep=1.79µs
    17:51:29.010179 Ino:12209562 typechange 0x4000 -> 0xa000, sleep=3.331µs
    17:51:29.010255 Ino:12209562 typechange 0x4000 -> 0xa000, sleep=4.537µs
    17:51:29.010364 Ino:12209562 typechange 0x4000 -> 0xa000, sleep=8.354µs
    17:51:29.010416 Ino:12209562 typechange 0x4000 -> 0xa000, sleep=8.897µs
        fsstress.3 seed = 1573917850
    17:51:33.623359 Ino:14291439 typechange 0x8000 -> 0x4000, sleep=0s
    17:51:33.623378 Ino:14291439 typechange 0x8000 -> 0x4000, sleep=1µs
    17:51:33.623392 Ino:14291439 typechange 0x8000 -> 0x4000, sleep=1.378µs
    17:51:33.644130 Ino:14291494 typechange 0x8000 -> 0x4000, sleep=0s
    17:51:33.644151 Ino:14291494 typechange 0x8000 -> 0x4000, sleep=1µs
    17:51:33.644159 Ino:14291494 typechange 0x8000 -> 0x4000, sleep=1.072µs
    17:51:33.654370 Ino:14291501 typechange 0x8000 -> 0x4000, sleep=0s
    17:51:33.654384 Ino:14291501 typechange 0x8000 -> 0x4000, sleep=1µs
    17:51:33.654393 Ino:14291501 typechange 0x8000 -> 0x4000, sleep=1.588µs
    17:51:33.654399 Ino:14291501 typechange 0x8000 -> 0x4000, sleep=2.639µs
    17:51:33.655098 Ino:14291476 typechange 0x4000 -> 0x8000, sleep=0s
    17:51:33.667216 Ino:14291504 typechange 0x4000 -> 0x8000, sleep=0s
    17:51:33.667228 Ino:14291504 typechange 0x4000 -> 0x8000, sleep=1µs
    17:51:33.667236 Ino:14291504 typechange 0x4000 -> 0x8000, sleep=1.443µs
    17:51:33.667242 Ino:14291504 typechange 0x4000 -> 0x8000, sleep=2.286µs
        rm
    3
        fsstress.1 seed = 1574749722
        fsstress.2 seed = 1574328972
    17:51:35.220180 Ino:13771167 typechange 0x8000 -> 0xa000, sleep=0s
    17:51:35.220205 Ino:13771167 typechange 0x8000 -> 0xa000, sleep=1µs
    17:51:35.514144 Ino:13771355 typechange 0x4000 -> 0xa000, sleep=0s
    17:51:35.514165 Ino:13771355 typechange 0x4000 -> 0xa000, sleep=1µs
    17:51:35.514172 Ino:13771355 typechange 0x4000 -> 0xa000, sleep=1.739µs
    17:51:35.515875 Ino:13771355 typechange 0x4000 -> 0xa000, sleep=1.969µs
    17:51:35.516021 Ino:13771355 typechange 0x4000 -> 0xa000, sleep=3.744µs
    17:51:35.516094 Ino:13771355 typechange 0x4000 -> 0xa000, sleep=4.308µs
    17:51:35.516514 Ino:13771355 typechange 0x4000 -> 0xa000, sleep=5.112µs
    17:51:35.516765 Ino:13771355 typechange 0x4000 -> 0xa000, sleep=5.299µs
    17:51:35.516870 Ino:13771355 typechange 0x4000 -> 0xa000, sleep=8.169µs
    17:51:36.429950 Ino:13771381 typechange 0x8000 -> 0xa000, sleep=0s
    17:51:36.430068 Ino:13771381 typechange 0x8000 -> 0xa000, sleep=1µs
    17:51:36.430082 Ino:13771381 typechange 0x8000 -> 0xa000, sleep=1.071µs
    17:51:36.547108 Ino:13899567 typechange 0x8000 -> 0x4000, sleep=0s
    17:51:36.547121 Ino:13899567 typechange 0x8000 -> 0x4000, sleep=1µs
    17:51:36.547158 Ino:13899567 typechange 0x8000 -> 0x4000, sleep=1.907µs
    17:51:36.547181 Ino:13899567 typechange 0x8000 -> 0x4000, sleep=2.358µs
    17:51:38.112588 Ino:13771503 typechange 0x8000 -> 0xa000, sleep=0s
    17:51:38.112602 Ino:13771503 typechange 0x8000 -> 0xa000, sleep=1µs
    17:51:38.112611 Ino:13771503 typechange 0x8000 -> 0xa000, sleep=1.11µs
    17:51:38.524020 Ino:13899675 typechange 0xa000 -> 0x8000, sleep=0s
    17:51:38.524042 Ino:13899675 typechange 0xa000 -> 0x8000, sleep=1µs

Change-Id: I6120ce76730018d22898127290f492fa9f85a957

TestTypeChange simulates inode number reuse that happens on real
filesystems. For go-fuse, inode number reuse can look like a file changing
to a directory or vice versa. Acutally, the old inode does not exist anymore,
we just have not received the FORGET yet.

The test fails reliably with iteration count 100. Will be fixed in the
next commit.

Test failure looks like this:

	~/go/src/github.com/hanwen/go-fuse/fs$ go test -run TestTypeChange -v
	=== RUN   TestTypeChange
	21:43:36.065494 rx 2: INIT i0 {7.31 Ra 0x20000 MAX_PAGES,SPLICE_READ,FLOCK_LOCKS,READDIRPLUS,READDIRPLUS_AUTO,ASYNC_DIO,WRITEBACK_CACHE,HANDLE_KILLPRIV,SPLICE_WRITE,PARALLEL_DIROPS,ABORT_ERROR,EXPLICIT_INVAL_DATA,NO_OPENDIR_SUPPORT,ASYNC_READ,BIG_WRITES,DONT_MASK,IOCTL_DIR,AUTO_INVAL_DATA,POSIX_ACL,CACHE_SYMLINKS,POSIX_LOCKS,ATOMIC_O_TRUNC,EXPORT_SUPPORT,SPLICE_MOVE,NO_OPEN_SUPPORT}
	21:43:36.065573 tx 2:     OK, {7.28 Ra 0x20000 PARALLEL_DIROPS,AUTO_INVAL_DATA,ASYNC_READ,BIG_WRITES,NO_OPEN_SUPPORT,READDIRPLUS 0/0 Wr 0x10000 Tg 0x0}
	21:43:36.065742 rx 4: LOOKUP i1 [".go-fuse-epoll-hack"] 20b
	21:43:36.065798 tx 4:     2=no such file or directory, {i0 g0 tE=0s tA=0s {M00 SZ=0 L=0 0:0 B0*0 i0:0 A 0.000000 M 0.000000 C 0.000000}}
	21:43:36.065837 rx 6: CREATE i1 {0100100 [WRONLY,CREAT,TRUNC,0x8000] (00)} [".go-fuse-epoll-hack"] 20b
	21:43:36.065861 tx 6:     OK, {i18446744073709551615 g0 {M0100644 SZ=0 L=1 0:0 B0*0 i0:18446744073709551615 A 0.000000 M 0.000000 C 0.000000} &{18446744073709551615 0 0}}
	21:43:36.065945 rx 8: POLL i18446744073709551615
	21:43:36.065954 tx 8:     38=function not implemented
	21:43:36.066009 rx 10: FLUSH i18446744073709551615 {Fh 18446744073709551615}
	21:43:36.066046 tx 10:     5=input/output error
	21:43:36.066065 rx 12: RELEASE i18446744073709551615 {Fh 18446744073709551615 WRONLY,0x8000  L0}
	21:43:36.066071 tx 12:     5=input/output error
	21:43:36.066107 rx 14: LOOKUP i1 ["file"] 5b
	21:43:36.066181 tx 14:     OK, {i1234 g0 tE=0s tA=0s {M0100644 SZ=0 L=0 0:0 B0*4096 i0:1234 A 0.000000 M 0.000000 C 0.000000}}
	21:43:36.066217 rx 16: GETATTR i1234 {Fh 0}
	21:43:36.066240 tx 16:     OK, {tA=0s {M0100644 SZ=0 L=0 0:0 B0*4096 i0:1234 A 0.000000 M 0.000000 C 0.000000}}
	21:43:36.066264 rx 18: LOOKUP i1 ["file"] 5b
	21:43:36.066285 tx 18:     OK, {i1234 g0 tE=0s tA=0s {M0100644 SZ=0 L=0 0:0 B0*4096 i0:1234 A 0.000000 M 0.000000 C 0.000000}}
	21:43:36.066301 rx 20: UNLINK i1 ["file"] 5b
	21:43:36.066321 tx 20:     OK
	21:43:36.066361 rx 24: LOOKUP i1 ["dir"] 4b
	21:43:36.066371 tx 24:     OK, {i1234 g0 tE=0s tA=0s {M0100644 SZ=0 L=0 0:0 B0*4096 i0:1234 A 0.000000 M 0.000000 C 0.000000}}
	21:43:36.066383 rx 22: FORGET i1234 {Nlookup=2}
	21:43:36.066390 rx 26: GETATTR i1234 {Fh 0}
	21:43:36.068259 tx 26:     OK, {tA=0s {M0100644 SZ=0 L=0 0:0 B0*4096 i0:1234 A 0.000000 M 0.000000 C 0.000000}}
	21:43:36.069664 received ENODEV (unmount request), thread exiting
	21:43:36.073309 received ENODEV (unmount request), thread exiting
	21:43:36.073396 received ENODEV (unmount request), thread exiting
	--- FAIL: TestTypeChange (0.01s)
	    bridge_test.go:96: should be a dir now
	FAIL
	exit status 1
	FAIL	github.com/hanwen/go-fuse/v2/fs	0.017s

Change-Id: I7a1a10303ecc0a8c008d29d5d81079868fc2cc43

As seen in debug logs like shown below, concurrent
FORGETs and inode number reuse could make use give
an Inode to the kernel that has already been deleted
from the nodes[] map.

With this change, I can no langer trigger a panic
in xfstests generic/007.

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

Nodes that appear to change type are not handled yet
(actually caused by inode number reuse), but this is
a separate problem.

Debug log:

  17:09:07.651735 rx 84444: CREATE i13632136 {0100644 [WRONLY,TRUNC,CREAT,0x8000] (022)} ["XXXXXXXXXXXX.38"] 16b
  17:09:07.651790 tx 84444:     OK, {i13632483 g1 {M0100644 SZ=0 L=1 0:0 B0*4096 i0:13632483 A 1572192547.650470 M 1572192547.650470 C 1572192547.650470} &{7 0 0}}
  [...]
  17:09:07.684439 rx 87988: CREATE i13632119 {0100644 [CREAT,TRUNC,WRONLY,0x8000] (022)} ["XXXXXXXXXXXX.37"] 16b
  [...]
  17:09:07.684472 rx 87992: FORGET i13632483 {Nlookup=1}
  17:09:07.684483 tx 87988:     OK, {i13632483 g1 {M0100644 SZ=0 L=1 0:0 B0*4096 i0:13632483 A 1572192547.683470 M 1572192547.683470 C 1572192547.683470} &{8 0 0}}
  [...]
  17:09:07.684557 rx 88006: FLUSH i13632483 {Fh 8}
  17:09:07.684560 unknown node 13632483
  17:09:07.684564 tx 88002:     OK,  "XXXXXXXXXXXX.830"
  panic: unknown node 13632483

Change-Id: Ibb1a7a6a459d2e4133a4e512e0816e8ed950a8d7

Getting rid of the "Mounted!" message makes it easier
to integrate into xfstests, which barks at all and any
unexpected output.

Used by https://github.com/rfjakob/fuse-xfstests/commit/ab1d77ccdb8cf16f79cb312bcb3aaadb23660807

Change-Id: Idff314474b4980ef6f6fc2460b338a840bb0e409

As pointed out by @slackner at
https://github.com/hanwen/go-fuse/commit/8581b7e950b2d520370eba8997ddd9493192e9c7#r35845728
FixMode() failed to take into account the length
of the file name and the padding.

To fix this without adding a lot of additional
pointer arithmetic, add the "lastDirent" field
to DirEntryList. This stores the last serialized
_Dirent, so _Dirent.Typ can be accessed easily
by FixMode().

Change-Id: I6ca3fe551e1a072779b1d5ed5293add057e55287

Add TestReaddirTypeFixup(). This test currently fails
because FixMode is broken. Will be fixed in a later commit.

Change-Id: Ie4eab9c5817ddb772b73aa22e8f75f5d4f2ad49c

Fixes issue #314

Change-Id: I6bf2d64d0e62c4881b7010c5c0421a16bd8d7db2

On OSX, Fh apparently is non-zero sometimes, even with FATTR_FH unset.

Fixes #329

Change-Id: I4d9b6a83a3a8e8fa615dfbfa4d1b132b752528da

Fixes #333

Change-Id: I51ac08baaf54884749bdc7356f524f8347ca6146

Go 1.9 fails to build the fs tests:

  # github.com/kylelemons/godebug/diff
  ../../kylelemons/godebug/diff/diff.go:50:13: undefined: strings.Builder
  ?   	github.com/hanwen/go-fuse/example/zipfs	[no test files]
  FAIL	github.com/hanwen/go-fuse/fs [build failed]

So drop Go 1.9.

Add Go 1.13, which is already at 1.13.3.

Change-Id: Id2286cddc3973a1388f94e1b294db36d7663c37b

When a directory is modified while READDIRPLUS is running,
the file type may change between readdir and lookup.

This patch adds the function FixMode() which allows to
overwrite the file type of the last serialized dirent.

Add test

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

Change-Id: Id45a9c4633e9abcb075588dc610ce8341d104825

open(2) has supports direct IO. When opening a file in the loopback
FS, writes to the underlying would fail, because the FUSE server does
not position the bytes to write (which come directly after the WriteIn
header) on a 512-byte boundary.

Fix this by allocating the input buffer with such that the first
content byte is aligned.

Add a test.

Fixes #328.

Change-Id: Ib7ad24aff673413ab8db4112d0b12143c2654617

As of Go 1.13, os.File doesn't allow WriteAt to O_APPEND. Since the
kernel translates writes to correct offsets, loopback does not have to
open the file as O_APPEND.

Fixes #325.

Change-Id: Ib1a7026b94b5604d415ac9fbb5850842dbeffc2a

Change-Id: I436dcd5f4a050ef082684af0705df9c51d6ff9e9

There are two types of DIRECT_IO. The one documented in open(2) and
FUSE's FOPEN_DIRECT_IO feature. This test exercises the latter.

Change-Id: Ie834b126318dedf5f65f0cf9805019ccda531797

Travis CI has a no-output-timeout of 10 minutes.
Set a lower test timeout so we get proper backtraces
on a hung test.

Actual test runtime should be about 1 minute.

Change-Id: I3fb40d13fb5bf9efc5e96f3551733205a7502481

gocryptfs has a similar test with somewhat more detailed
parsing of the open fds. Import the ListFds function from
gocryptfs and use it to make the error more informative.

Change-Id: I2442364e2e5d49749683072b91bda5691ad8902e

These are not actual directories, and adding them to
our tree causes directory cycles, so don't.

Before this change, running

  $ ./extractloop.bash -loopback

from https://github.com/rfjakob/gocryptfs/tree/master/tests/stress_tests
quickly caused loopback to get stuck and consume all
available memory. Things look stable now.

Add a test to verify that rawBridge does not call LOOKUP
on "." and "..".

Also, add a comment to the "for pd = range p.parents" loop,
that has caused some head-scratching during debugging.

Change-Id: I15eedeee30043dc57e5fa580fefe59a48674b193

Even when the directory stream does not have additional
entries, we may still have an entry in the overflow slot.

Don't forget about it. Test now passes:

  go-fuse/fs$ go test
  PASS
  ok  	github.com/hanwen/go-fuse/v2/fs	0.582s

Change-Id: I98b39d4e7df235ed57ae4bf2702532f3b17d1bd0

There is an unhandled corner case in the directory stream
handling. The stricter test catches it:

  go-fuse/fs$ go test
  --- FAIL: TestPosix (0.20s)
      --- FAIL: TestPosix/ReadDir (0.09s)
          test.go:342: got 19 entries, want 20
          test.go:342: got 40 entries, want 41
          test.go:342: got 61 entries, want 62
          test.go:342: got 82 entries, want 83
          test.go:342: got 103 entries, want 104
  FAIL
  exit status 1
  FAIL	github.com/hanwen/go-fuse/v2/fs	0.610s

Fix comes next.

Change-Id: I3e22904fce96bf2264ede47656ebd2936a7d13cd

Filesystems usually show the underlying device in the first
column of df. Follow suite and show the original dir, making
"df" and "mount" output more useful.

The actual reason for this change, however, is that it facilitates
running xfstests against go-fuse loopback. The xfstests machinery
checks that the expected device is mounted at the right place.

Commit https://github.com/rfjakob/fuse-xfstests/commit/182841fea487419f493d9b547bf703bee9e39322
adds support for go-fuse loopback to xfstests and depends on this
change.

Before:

  $ df -T
  Filesystem                 Type           1K-blocks       Used Available Use% Mounted on
  loopback                   fuse.loopback  237371192  149885928  75357828  67% /home/jakob/go/src/github.com/hanwen/go-fuse/example/loopback/b

After:

  $ df -T
  Filesystem                 Type           1K-blocks       Used Available Use% Mounted on
  a                          fuse.loopback  237371192  150332024  74911732  67% /home/jakob/go/src/github.com/hanwen/go-fuse/example/loopback/b

Change-Id: I3d5a2e7ab021af4eed657e66654b636e08292219

Per default, "rawBridge" is shown here, which does not tell the user
much about the filesystem. Set to "loopback" as shown below.

Before:

  $ df -T
  Filesystem                 Type            1K-blocks       Used Available Use% Mounted on
  rawBridge                  fuse.rawBridge  237371192  149873220  75370536  67% /home/jakob/go/src/github.com/hanwen/go-fuse/example/loopback/b

After:

  $ df -T
  Filesystem                 Type           1K-blocks       Used Available Use% Mounted on
  loopback                   fuse.loopback  237371192  149885928  75357828  67% /home/jakob/go/src/github.com/hanwen/go-fuse/example/loopback/b

Change-Id: Iaaa18b4193b31567f6589669e8c443715afbd362

Add posix.LinkUnlinkRename to test this behavior; this is the approach
that git uses for writing pack files.

Thanks to Nicola Girardi <idrarig.alocin@gmail.com> for reporting this
bug.

Change-Id: Idb34e32f1dbb3c6c617aa82e29c4f0ac6f8a544d

Change-Id: Ie50ade19cf86abbbc6d6d5710f26ca03d7873098

Failure was:

    zipfs_test.go:74: got block count 8, want 1

This got broken by "fs: set Blksize and Blocks automatically based on Size",
fix it by setting Blksize.

Change-Id: I1d3798082b2e8a7fcda908b9b88d8b51fb11da78