update changelog

When the kernel sends a `Create` message the WinFsp-FUSE layer creates
and opens the file (as per Windows semantics). Sometimes an additional
operation needs to be performed after the file has been opened, which
may fail. In this case the just opened file must be released.

In this particular case the WinFsp-FUSE layer used to call `release`
with an uninitialized path. This commit fixes the problem.

This problem was originally reported in cgofuse (billziss-gh/cgofuse#58)

Changelog.asciidoc

@@ -1,6 +1,26 @@
 = Changelog
 
 
+v1.10B2 (2021.1 Beta2)::
+
+Changes since v1.9:
+
+* [NEW] WinFsp now supports rebranding of the build products. This is primarily useful to commercial licensees. See https://github.com/billziss-gh/winfsp/wiki/WinFsp-Rebranding for more information.
+
+* [NEW] WinFsp-FUSE has a new method for determining file access in the case where the user's primary SID (Windows Security Identifier) and group SID are the same (for example, this can happen when someone uses a Microsoft account as their primary login).
+** Previously when the user SID and group SID were the same WinFsp-FUSE looked at the UNIX permissions for the owner and the UNIX permissions for the group and used the MOST restrictive permissions, which often resulted in inadvertent "access denied" errors. (For example, if the owner permission was `rw-` and the group permission was `---` the result was `---` and therefore access denied).
+** Going forward this behavior will change. The user and group mode permissions will not be considered together even in the case where the user SID and group SID are the same. This will resolve the access denied errors.
+** However to preserve backward compatibility (there might be some file systems that rely on the old behavior) we will do so in stages. For release v1.10 (2021.1) there is a new registry setting under `HKLM\SOFTWARE\WinFsp` (or `HKLM\SOFTWARE\WOW6432Node\WinFsp` on a 64-bit system) called `DistinctPermsForSameOwnerGroup`, which if set to 1 will direct WinFsp-FUSE to use the new behavior. The default value is 0 which directs WinFsp-FUSE to use the old behavior. This default will change in a future release.
+
+* [FIX] File share access when overwriting a file (e.g. when using `TRUNCATE_EXISTING`) is now done in a manner compatible with NTFS (previously there were cases when overwriting a file where behavior diverged from the NTFS one). (See GitHub issue #364.)
+
+* [FIX] Fixed a problem in the file system shutdown protocol which resolves an occasional access violation in the user mode file system process. Previously it was possible for a file system to crash when stopping itself using `FspFileSystemStopDispatcher`; this problem has been rectified. (See GitHub issue #369.)
+
+* [FIX] Fixed a problem in the FUSE layer where in some rare circumstances the `release` operation could be called with an uninitialized `path` argument. (See GitHub issue billziss-gh/cgofuse#58 and commit f51bdef53427d1bba688fb6c768792fdc22ffc7b).
+
+* [FIX] The `winfsp.h` header no longer defines `FILE_FULL_EA_INFORMATION` when compiled under mingw. This is because the mingw tool chain already includes a definition of this type. (GitHub PR #371. Thanks @lemourin.)
+
+
 v1.10B1 (2021.1 Beta1)::
 
 Changes since v1.9:

build/VStudio/version.properties

@@ -19,7 +19,7 @@
 
         <MyCanonicalVersion>1.10</MyCanonicalVersion>
 
-        <MyProductVersion>2021.1 Beta1</MyProductVersion>
+        <MyProductVersion>2021.1 Beta2</MyProductVersion>
         <MyProductStage>Beta</MyProductStage>
 
         <MyVersion>$(MyCanonicalVersion).$(MyBuildNumber)</MyVersion>

doc/Known-File-Systems.asciidoc

@@ -1,6 +1,6 @@
 = Known File Systems and File System Libraries
 
-This document contains a list of known file systems and file system libraries that run on WinFsp. Please contact the WinFsp project to have your file system solution added to this list.
+This document contains a list of known open-source file systems and file system libraries that run on WinFsp. Please contact the WinFsp project to have your file system solution added to this list.
 
 == File Systems
 
@@ -9,13 +9,16 @@ This document contains a list of known file systems and file system libraries th
 - https://github.com/lowleveldesign/fsmemfs[fsmemfs] - Memory File System written in F#
 - https://github.com/ihaveamac/fuse-3ds[fuse-3ds] - FUSE Filesystem Python scripts for Nintendo 3DS files
 - https://github.com/sganis/golddrive[golddrive] - Windows ssh network drive
+- https://github.com/billziss-gh/hubfs[hubfs] - File system for GitHub
 - https://github.com/FrKaram/KS2.Drive[KS2.Drive] - Mount a webDAV/AOS server as a local drive
 - https://github.com/billziss-gh/nfs-win[nfs-win] - NFS for Windows
+- https://github.com/billziss-gh/objfs[objfs] - Object Storage File System
 - https://github.com/ncw/rclone[rclone] - rsync for cloud storage
 - https://github.com/hasse69/rar2fs[rar2fs] - FUSE file system for reading RAR archives
 - https://github.com/billziss-gh/redditfs[redditfs] - ls -l /r/programming
 - https://github.com/netheril96/securefs[securefs] - Filesystem in userspace (FUSE) with transparent authenticated encryption
 - https://github.com/billziss-gh/sshfs-win[sshfs-win] - SSHFS for Windows
+- https://github.com/printpagestopdf/WordpressDrive[WordpressDrive] - Windows Userspace Filesystem based on WinFsp that presents a Wordpress Site as a Windows Drive
 - https://github.com/emoose/xbox-winfsp[xbox-winfsp] - Adds native support to Windows for the FATX, STFS & GDFX (aka XGD/XDVDFS) Xbox filesystems.
 - https://github.com/UtrechtUniversity/YodaDrive[YodaDrive] - Mount a Yoda drive as a local drive
 

src/dll/fuse/fuse_intf.c

@@ -951,12 +951,12 @@ exit:
             if (CreateOptions & FILE_DIRECTORY_FILE)
             {
                 if (0 != f->ops.releasedir)
-                    f->ops.releasedir(filedesc->PosixPath, &fi);
+                    f->ops.releasedir(contexthdr->PosixPath, &fi);
             }
             else
             {
                 if (0 != f->ops.release)
-                    f->ops.release(filedesc->PosixPath, &fi);
+                    f->ops.release(contexthdr->PosixPath, &fi);
             }
         }