X-Recipient: archive-cygwin AT delorie DOT com
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org B84933858401
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1709802436;
	bh=gA8OmnX6moLe38VjPjGruWMyXm7+3h7Mn5Kwgq83WNk=;
	h=Date:To:Subject:References:In-Reply-To:List-Id:List-Unsubscribe:
	 List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc:
	 From;
	b=TkFKKYWnE+/+c3WY5KZcQxCIkf8QHSKfBCUwZgahPe7ISKZlKo7uMyd1Zz9vBLW4k
	 MBBlSs0cdvZ9cBFOAgsgarRm/596+qialjeFDzQbFN+c+aD7xbNqGwpK/kLJoP+NRk
	 qbekSpyYwG6dCctui/GUKDw5ODpW6HO7V522vrY4=
X-Original-To: cygwin AT cygwin DOT com
Delivered-To: cygwin AT cygwin DOT com
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 30DE03858D39
Date: Thu, 7 Mar 2024 10:06:51 +0100
To: Jeffrey Altman <jaltman AT secure-endpoints DOT com>
Subject: Re: ls/stat on OneDrive causes download of files
Message-ID: <ZemDq4Qa7NLUJYWj@calimero.vinschen.de>
Mail-Followup-To: Jeffrey Altman <jaltman AT secure-endpoints DOT com>,
 cygwin AT cygwin DOT com
References: <CAC9GOO-RbcR5YOPyk6qVDuVSdDK4M=f1V8bHvz7yvoaHjGUZnQ AT mail DOT gmail DOT com>
 <ZehuDAKd3ceXlfba AT calimero DOT vinschen DOT de>
 <ZehvbhVizZTBSaRR AT calimero DOT vinschen DOT de>
 <208962d1-78cd-4e2d-9e4a-a1edcbf5e809 AT SystematicSW DOT ab DOT ca>
 <ZeilkJK7Csryuzkc AT calimero DOT vinschen DOT de>
 <7d9fe460-5704-424b-a89b-e34ef2176d38 AT secure-endpoints DOT com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <7d9fe460-5704-424b-a89b-e34ef2176d38@secure-endpoints.com>
X-BeenThere: cygwin AT cygwin DOT com
X-Mailman-Version: 2.1.30
Precedence: list
List-Id: General Cygwin discussions and problem reports <cygwin.cygwin.com>
List-Unsubscribe: <https://cygwin.com/mailman/options/cygwin>,
 <mailto:cygwin-request AT cygwin DOT com?subject=unsubscribe>
List-Archive: <https://cygwin.com/pipermail/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-request AT cygwin DOT com?subject=help>
List-Subscribe: <https://cygwin.com/mailman/listinfo/cygwin>,
 <mailto:cygwin-request AT cygwin DOT com?subject=subscribe>
From: Corinna Vinschen via Cygwin <cygwin AT cygwin DOT com>
Reply-To: cygwin AT cygwin DOT com
Cc: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>, cygwin AT cygwin DOT com
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: cygwin-bounces+archive-cygwin=delorie DOT com AT cygwin DOT com
Sender: "Cygwin" <cygwin-bounces+archive-cygwin=delorie DOT com AT cygwin DOT com>

Hi Jeffrey,


apart from the attribute stuff...


On Mar  6 13:55, Jeffrey Altman via Cygwin wrote:
> The default ProcessPlaceholderCompaibilityMode is PHCM_EXPOSE_PLACEHOLDERS
> which makes the FILE_ATTRIBUTE flags and reparse tags visible. Microsoft
> maintains a database of processes for which PHCM_DISGUISE_PLACEHOLDER is set
> which hides that information. Its unclear to me that explicitly setting the
> placeholder compatibility mode is useful.

What I see as a problem here is this:

https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/ntifs/nf-ntifs-rtlsetprocessplaceholdercompatibilitymode

Quote:

  "Most Windows applications see exposed placeholders by default. For
   ^^^^
   compatibility reasons, Windows may decide that certain applications
                          ^^^^^^^^^^^^^^^^^^
   see disguised placeholders by default."

But then again, in other news from Microsoft:

https://learn.microsoft.com/en-us/windows/win32/cfapi/build-a-cloud-file-sync-engine#compatibility-with-applications-that-use-reparse-points

Quote:

  "[...] the cloud files API always hides its reparse points from all
                             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   applications except for sync engines and processes whose main image
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   resides under %systemroot%. Applications that understand reparse
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^
   points correctly can force the platform to expose cloud files API
   reparse points using RtlSetProcessPlaceholderCompatibilityMode or
   RtlSetThreadProcessPlaceholderCompatibilityMode.

Considering these two statements, it's totally unclear to a process, if
it just defaults to "exposed" or "disguised".

Fortunately we can ask Windows by calling the
RtlQueryProcessPlaceholderCompatibilityMode() function, right?

Lets have a look into the documentation at
https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/ntifs/nf-ntifs-rtlqueryprocessplaceholdercompatibilitymode

Quote:

  "Return value

  This function returns the process's placeholder compatibily mode
  (PHCM_xxx), or a negative value on error (PCHM_ERROR_xxx). Contains
  one of the following values:

  Compatibility Mode           Value
  PHCM_APPLICATION_DEFAULT       0
  PHCM_DISGUISE_PLACEHOLDER      1
  PHCM_EXPOSE_PLACEHOLDERS       2
  PHCM_MAX                       2
  PHCM_ERROR_INVALID_PARAMETER  -1
  PHCM_ERROR_NO_TEB             -2"

So I called the function right at the start of the Cygwin DLL, and it
returns the value 0, i. e., PHCM_APPLICATION_DEFAULT.

At this point the process *still* has no idea if placeholders are
exposed or disguised.  What a great API! \o/

So, from the above, and if we really want to be sure that placeholders
will be exposed, I don't see any way around calling
RtlSetProcessPlaceholderCompatibilityMode(PHCM_EXPOSE_PLACEHOLDERS)
explicitely at DLL startup.

What do you think?


Thanks,
Corinna

-- 
Problem reports:      https://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple