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

Change-Id: I272909148667e1f0246914ef7fdd1052bf3b5bc3

Change-Id: I1c098b6c06ab62aa7877e47aa3d99f37e9a83e5c

Change-Id: Iac5c1a8329ceb0d8538029bd737cfede2af4d9a2

Change-Id: I811c6a070bfdc3582da816f302354f4a7516beab

Change-Id: I7dfd919df765679bf9c09ec74cefc6c53bfc56b3

Travis CI appears to be too slow for the race detector. 

Change-Id: I5f4e7dc379938cf8000ab2d8ba95e09fab8ed6c9

Pool.Get() can trigger a GC, and we see this GC being hung in stack
traces for the TestDeleteNotify test case.

See issue #261.

Change-Id: I278a05fc3c6a59c701686aebd410511c5502d9d5

Reported-by: Philipp Gillé
Change-Id: I3db9f54016c17744bafa57a813531a99c01e47fa

The API is poorly thought out, as a node can be child in multiple
parents with the same name. Similary, a reversing keys and values is
not possible. A child may have the same parent with different names.

Change-Id: I3888606016b56f06d80ef56ebc7b8725a819c1a9

Change-Id: I451f56511a2b796c6a90df49e6c288d6675af363

Change-Id: I9d9e7a098c0b2de29aad78a6938e39867522f919

Change-Id: Ie5c189f220ebebaf7da8813d9092649619fb2b8d

This makes the default setting more useful.

Change-Id: Iab40ad0ab0e2c9b75b786a883f6ad989178ee5b5

Change-Id: I3464790cd8fd05a4f0e787a3895bf3e81569b29a

This speeds them up, and avoids writing to log files, decreasing
chances of flakiness.

Change-Id: I2a8f254d085303143285d2812e297e879d145652

Change-Id: I71cd7cb713c7e864305ebad73a1b072395c13b27

This simplifies writing R/O filesystems, which do not need flushing.

Change-Id: I428627799904e30f486ff82bcafe2f9c4db88d01