Fixed bug #79470: PHP incompatible with 3rd party file system on demand #5379
Conversation
Update tsrm_realpath_r() to handle unknown reparse tags with default behavior that matches how IO_REPARSE_TAG_DEDUP, IO_REPARSE_TAG_CLOUD, IO_REPARSE_TAG_ONEDRIVE were handled previously. In general the default behavior for 3rd party files systems with non public reparse tags will be using default behavior instead of having to be added explicitly to PHP in order to be supported. This change keeps existing behavior and expands the behavior to future or non-public "Fetch On Demand" file systems.
|
Thanks for the PR (and also the information in the bugtracker)! It seems to me that we must not assume that any reparse point except for Anyhow, could you please check your reparse points with PS: relevant link for futher lookup: https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-fscc/c8e77b37-3909-4fe6-a4ea-2b9d423b1ee4 |
|
Adding Wade Brainerd for transparency. Wade works on our custom File System
On Demand Tool and recently mentioned that our Reparse Tag is in process of
being published to NTFS headers so that eventually it will be listed in:
https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-fscc/c8e77b37-3909-4fe6-a4ea-2b9d423b1ee4
Perhaps as a fallback plan we could update PHP to contain the handling of
this reparse tag much like OneDrive's...
fsutil lists Reparse Tag Value as:
Reparse Tag Value : 0x00000047
…On Wed, Apr 15, 2020 at 8:30 AM Christoph M. Becker < ***@***.***> wrote:
Thanks for the PR (and also the information in the bugtracker
<https://bugs.php.net/bug.php?id=79470#1586802236>)!
It seems to me that we must not assume that any reparse point except for
IO_REPARSE_TAG_SYMLINK and IO_REPARSE_TAG_MOUNT_POINT resolves to itself;
at the very least we should assume that !IsReparseTagNameSurrogate() does
not. And even with this amendment, I'm reluctant to make this change for
the stable PHP versions (7.3 being particularly problematic). @weltling
<https://github.com/weltling>, thoughts?
Anyhow, could you please check your reparse points with fsutil
reparsePoint query <filename>, and post the results (the "Reparse Tag
Value" should be sufficient).
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#5379 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AMHFPHYWCIGUNM4XOPKVIOTRMXHH3ANCNFSM4MGZ4DPQ>
.
|
|
Hi, our reparse tag is found in ntifs.h in the Windows 10 SDK here: //
// Tag allocated to Activision for HSM
// GUID: 18CC35B3-5DFF-408E-B42E-9FA6731BC506
//
#define IO_REPARSE_TAG_ACTIVISION_HSM (0x00000047L)
Actually, I think that you must- reparse points are used for many functions besides links, and if the application doesn't know specifically what the reparse tag means it must make no assumptions about the meaning and treat it as an ordinary file. Other libraries with filesystem abstractions such as libuv take this approach (https://github.com/libuv/libuv/blob/master/src/win/fs.c#L1693).
This seems like a reasonable compromise, but I don't know what you can do with a link that you cannot read- seems better to just let the filesystem handle it. |
|
Thanks for the further information!
This is about PHP's implementation of
So I think we should better reject "unknown" reparse tags which are I tend to agree that we should accept all other reparse tags (not only I would like to get more insights on this topic. :) |
|
Maybe the best course of action would be to extend the existing OneDrive codepath to cover the Git VFS and the Activision tags in the stable release, and then to put the more generic solution into development builds. Since it's simply extending an existing check to cover our tag, and our tag isn't present in the wild, it feels like it would be a safe change to make in a stable release. |
I agree that this looks like the best way forward. @weltling, @dalehhirt, what do you think? |
|
I have just submitted PR #5451, which just adds support for |
|
Hi Christoph,
I've compiled your changes and tested with our on demand file system. The
changes you made work.
Appreciated.
…On Fri, Apr 24, 2020 at 8:36 AM Christoph M. Becker < ***@***.***> wrote:
I have just submitted PR #5451 <#5451>,
which just adds support for IO_REPARSE_TAG_ACTIVISION_HSM and
IO_REPARSE_TAG_PROJFS. While I have tested the latter, I cannot test the
former, so @gilbertjgonzales <https://github.com/gilbertjgonzales> or
@wadetb <https://github.com/wadetb>, could you please test that PR,
please? If there are no issues, I'd like to merge the other PR on Monday,
so the fix would make it into 7.3.18RC1.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#5379 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AMHFPH63IF3CN7UBPB3QCTTROGWYBANCNFSM4MGZ4DPQ>
.
|
|
Thanks for checking! I have merged the other PR, but will keep this one open as a reminder that we might want to have a more general solution for master. I'll see to that ASAP. |
|
PR #5565 for general support is now available, so I'm closing this PR. Thanks again for having worked on this! |
Update tsrm_realpath_r() to handle unknown reparse tags with
default behavior that matches how
IO_REPARSE_TAG_DEDUP, IO_REPARSE_TAG_CLOUD,
IO_REPARSE_TAG_ONEDRIVE were handled previously.
In general the default behavior for 3rd party files systems
with non public reparse tags will be using default behavior
instead of having to be added explicitly to PHP in order to
be supported.
This change keeps existing behavior and expands the behavior to
future or non-public "Fetch On Demand" file systems.