DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:from:to:subject:date:message-id:references
	:in-reply-to:content-type:content-id:content-transfer-encoding
	:mime-version; q=dns; s=default; b=pzGMZjsvL+GbI7qdFek/Idy1PXHHn
	u8TtB8GtHM3VcpHQUddAKeGBo8CAlsev7KBooLoBHx5vOhNnhm2yKzTb/Yp4zH1D
	u05maetwGt4lqnXANihOJw2xC19fRrwsqogICiFSpsabi5wd/n9uVevfXBQ8fWpM
	1J8cHjYMXGEKvM=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
From: Bill Zissimopoulos <billziss AT navimatics DOT com>
To: "cygwin AT cygwin DOT com" <cygwin AT cygwin DOT com>
Subject: Re: FUSE, symbolic links and special files
Date: Thu, 25 Aug 2016 19:04:10 +0000
Message-ID: <D3E512D6.AF5F%billziss@navimatics.com>
References: <D3E490C7.AEB9%billziss AT navimatics DOT com> <20160825124512 DOT GE9783 AT calimero DOT vinschen DOT de>
In-Reply-To: <20160825124512.GE9783@calimero.vinschen.de>
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-office365-filtering-correlation-id: 93791835-5cbb-4f18-b853-08d3cd1a98f1
x-microsoft-exchange-diagnostics: 1;CY1PR07MB2197;6:EAH3gTuJ3aRaYX7Pjn/676UmaUKT+Wl44bjWOQccpsOkif5jQj0x4sectx/i78g/Wid4KdiCLfAWQx4TLyEIfXPwwW53/Ez+zoI2s8aGc8pswOiEWi9qyHcvR5ZFQFFRh8hwLwlT7447xdwOnmlMvc6a1xpCp4/JGBBCdJDcvm5YbMGPTOhf9EbRl65Rz0hz8audLPxgv5OTc9yyulmDONSQFqd+5jmU+fR5RUTIjDCTyJsjlSHVtVHGlP0sR+aBC2iCjvKhX/eA6QwgT/8uqQXlkyBQkPzZVNF8ZeRvGDtcz0UVtELSftU7I3D+xCB2;5:Sl+YI1Ca0Njc6/H4FreKk7Q0zzgsFk7WrzmPsd5h2l7FmjOsTOgmleyDzYSRA477gBi32XjcHOUSRefsITraSn4HFhCBNefmBcNPHhL5TnPf/Y6/i+uesogSMCjK2d0fGnHFNhfLZnHiNZWcDeM1VQ==;24:wodoM6/p3HdnQ7nmLy33f7nrZU8MVZx0H8IkKA1Er3TBXn/nxdQDDd4NgDJZXNdAaGIZJYvZh2kPNJsoYcBevz7ACvtgY+ZJoG7dQxVAaaI=;7:cCpNnvtl1XF4U6Q+dsb8mDxfCGgn6yI602yfp1pwIDjOcVxbG4R9GCH9fB4fhhNkHPrkGNWSJZeH/NvX/PXv2Wdf5GPUefRkjFmbSEQRtZr4G92lQvwgVT9cIOQxvJDvRq2EV2GYAQxWiM6HYLBjleHxpQrEqrlYlRxqThOQ1Ie6+Co2atHZK9fZ0sdBrOAkdMtb79XTdGhNxfBDi3yhx5lVSCtNtVBaUkZnVtc1Q8Ta2ZV0BLj81sBqtnGfcmoY
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR07MB2197;
x-microsoft-antispam-prvs: <CY1PR07MB2197349E063AA73D469ED1FDBCED0 AT CY1PR07MB2197 DOT namprd07 DOT prod DOT outlook DOT com>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6043046)(6042046);SRVR:CY1PR07MB2197;BCL:0;PCL:0;RULEID:;SRVR:CY1PR07MB2197;
x-forefront-prvs: 0045236D47
x-forefront-antispam-report: SFV:NSPM;SFS:(10019020)(6009001)(7916002)(377454003)(24454002)(69234005)(199003)(189002)(5640700001)(3660700001)(122556002)(81156014)(77096005)(86362001)(1730700003)(106116001)(8676002)(106356001)(81166006)(87936001)(3846002)(7736002)(11100500001)(102836003)(10400500002)(36756003)(105586002)(189998001)(8936002)(7846002)(6116002)(99286002)(66066001)(5002640100001)(450100001)(50986999)(92566002)(101416001)(76176999)(54356999)(586003)(2351001)(2906002)(2501003)(107886002)(305945005)(5660300001)(3280700002)(97736004)(2950100001)(68736007)(2900100001)(110136002)(94096001);DIR:OUT;SFP:1102;SCL:1;SRVR:CY1PR07MB2197;H:CY1PR07MB2199.namprd07.prod.outlook.com;FPR:;SPF:None;PTR:InfoNoRecords;A:1;MX:1;LANG:en;
received-spf: None (protection.outlook.com: navimatics.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <72CE0D2F13237940A3702228F2276B26 AT namprd07 DOT prod DOT outlook DOT com>
MIME-Version: 1.0
X-OriginatorOrg: navimatics.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Aug 2016 19:04:10.2419 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 21071be9-4f9a-413b-89ac-8353a5d2410a
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR07MB2197
X-IsSubscribed: yes
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by delorie.com id u7PJ4bkF009828

On 8/25/16, 3:45 PM, Corinna Vinschen wrote:

>On Aug 25 11:46, Bill Zissimopoulos wrote:
>>In the following OP is the originating process, CW is the Cygwin
>> layer, WL is the WinFsp layer and FL is the FUSE layer.
>> 
>> OP: mkfifo("myfifo")
>> CW: NtCreateFile, NtDeviceIoControlFile(FSCTL_SET_REPARSE_POINT)
>> [NFS_SPECFILE_FIFO]
>> WL: IRP_MJ_FILE_SYSTEM_CONTROL/FSCTL_SET_REPARSE_POINT
>>[NFS_SPECFILE_FIFO]
>> FL: fuse_operations::mknod("myfifo", S_IFIFO)
>> 
>> Regarding symbolic link support specifically I am still undecided on
>> whether the right thing to do is to use NTFS symbolic links
>> (IO_REPARSE_TAG_SYMLINK) or use NFS_SPECFILE_LNK for the FUSE layer. My
>> inclination is to support both and let the FUSE file system developer
>> decide on their preference.
>> 
>> Any comments welcome.
>
>...it needs thorough testing(*).  There's a good chance that the NFS RP
>buffer is not exposed to user space, but instead only handled by the NFS
>driver.  *If* the RP method works fine in user space, I'm inclined to do
>as outlined above and get rid of the EA stuff in symlink_info::check
>since it could be transparently shared between NFS and WinFSP.

I agree. FYI I have not tested the use of NFS reparse points yet, although
I intend to.

My expectation is that there should not be any issue accessing such
reparse points from user mode. My understanding of the reparse point
mechanism is that it comes into play in a couple of cases:

- The first case is during the processing of NtCreateFile (without the
FILE_OPEN_REPARSE_POINT flag set). In this case the file system driver
will return STATUS_REPARSE and either:
	- Return a path that NTOS will resend to the file system driver for
further processing (useful for symlink-style processing), or...
	- Return a reparse data buffer that some higher-level component (e.g. a
filter driver) may interpret specially. For example, a hierarchical
storage management system may download a file pointed to by a reparse
point locally. If there is no higher-level component that knows about the
reparse point, I believe the NTOS IO manager will return
STATUS_IO_REPARSE_TAG_NOT_HANDLED.

- The second case is through direct manipulation of the reparse point
using FSCTL_GET_REPARSE_POINT, FSCTL_SET_REPARSE_POINT and
FSCTL_DELETE_REPARSE_POINT.

Let us consider the expected behavior of an NFS_SPECFILE_LNK reparse point
(this is speculation) during NtCreateFile:

- On NTFS prior to Win8:
	- STATUS_IO_REPARSE_TAG_NOT_HANDLED

- On NFS prior to Win8:
	- STATUS_IO_REPARSE_TAG_NOT_HANDLED

- On FUSE for Cygwin prior to Win8:
	- STATUS_SUCCESS with file pointed by symlink opened (because the WinFsp
FSD would know how to handle NFS reparse points).

- On NTFS after Win8:
	- Likely STATUS_IO_REPARSE_TAG_NOT_HANDLED, although there is a
possibility that Microsoft has built knowledge of the NFS_SPECFILE_LNK
reparse point into the NTFS FSD or another filter driver, in which case
the file would be opened and the return would be STATUS_SUCCESS.

- On NFS after Win8:
	- STATUS_SUCCESS with file pointed by symlink opened.

- On FUSE for Cygwin prior to Win8:
	- STATUS_SUCCESS with file pointed by symlink opened.


This is not ideal, because sometimes an NtCreateFile of an
NFS_SPECFILE_LNK reparse point will result in STATUS_SUCCESS and sometimes
it will result in STATUS_IO_REPARSE_TAG_NOT_HANDLED. I can imagine of
course that the NtCreateFile call could be retried with
FILE_OPEN_REPARSE_POINT followed by FSCTL_GET_REPARSE_POINT and symlink
resolution could happen in user mode.

Bill