ls/stat on OneDrive causes download of files

[Corinna Vinschen]

Hi Jeffrey,


looks like writing our mails overlapped:
https://cygwin.com/pipermail/cygwin/2024-March/255622.html

On Mar  6 13:55, Jeffrey Altman via Cygwin wrote:
> On 3/6/2024 12:19 PM, Corinna Vinschen via Cygwin wrote:
> > We can add an explicit call to
> > 
> >    RtlSetProcessPlaceholderCompatibilityMode (PHCM_EXPOSE_PLACEHOLDERS);
> > 
> > and we can recognize the IO_REPARSE_TAG_FILE_PLACEHOLDER and
> > IO_REPARSE_TAG_CLOUD_* tags during symlink evaluation, but even then
> > we still have to know what the reparse point buffer actually contains.
> > 
> > Given that the content of reparse points with these reparse tags are
> > undocumented, some people using cloud services should examine these
> > reparse points so we can add some suitable code to Cygwin.
> > 
> > 
> > Corinna
> I'm not an expert in this area by any means but here are my recollections
> from when Microsoft presented in-person on cloud placeholders to filter and
> filesystem developers many years ago.
> 
> Files and directories that are placeholders should have either the
> FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS or FILE_ATTRIBUTE_RECALL_ON_OPEN file
> attributes set. When these attributes are set, applications and mini filters
> are advised not to "read" or "open" the files or directories unless they
> absolutely need to

Per https://learn.microsoft.com/en-us/windows/win32/fileio/file-attribute-constants
FILE_ATTRIBUTE_RECALL_ON_OPEN only appears in directory listing
classes, but not in standard FILE_BASIC_INFORMATION and alike.
That's a bit of a problem considering how we check files during
path conversion.

The MSDN article doesn't state the same for
FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS, which is good, I think.

But I'm a bit puzzled then in terms of FILE_ATTRIBUTE_OFFLINE.  Is it
not used for OneDrive files?

> [...]
> I'm not sure that exposing the object as a symlink is a good idea.

Yeah, that's what I realized as well, see my aforementioned mail.

> Perhaps the question that needs to be asked is whether there are opens that
> can be skipped if an object is known to not be locally present (either of
> the FILE_ATTRIBUTE flags are set)?

This may be the way to go, see my mail.  It wouldn't be much of
a problem to check all attribute bits, i.e. FILE_ATTRIBUTE_OFFLINE,
FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS and FILE_ATTRIBUTE_RECALL_ON_OPEN.
Maybe that's what we should do.


Thanks,
Corinna