Re: Cygwin 3.5.1: unable to open output file '/cygdrive/t/tmpdir/x-01564d.o': 'Operation not permitted'

[Cedric Blancher via Cygwin]

On Fri, 8 Mar 2024 at 03:25, Dan Shelton via Cygwin  wrote:
>
> Hello!
>
> I've run into a problem with clang on Cygwin 3.5.1 and 3.6. My machine
> does not have much disk space left, so I switched TMPDIR to the
> network drive. But clang then failed, like this:
>
> $ cat x.c
> #include 
> int main(int ac, char *av[]) { puts("hello world"); return 0 ; }
> $ mkdir /cygdrive/t/tmpdir
> $ TMPDIR=/cygdrive/t/tmpdir clang x.c
> error: unable to open output file '/cygdrive/t/tmpdir/x-01564d.o':
>   'Operation not permitted'
> 1 error generated.
>
> /cygdrive/t/tmpdir/ is a clean dir.
> /usr/bin/touch /cygdrive/t/tmpdir/dummy works without problems
>
> How can I debug this further?
>

Which "network drive" do you use? SMB, AFS, Microsoft NFSv3,
msnfs41client NFSv4.1, OpenText Exceed NFSv3/NFSv4?

Ced
-- 
Cedric Blancher 
[https://plus.google.com/u/0/+CedricBlancher/]
Institute Pasteur

-- 
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

Cygwin 3.5.1: unable to open output file '/cygdrive/t/tmpdir/x-01564d.o': 'Operation not permitted'

[Dan Shelton via Cygwin]

Hello!

I've run into a problem with clang on Cygwin 3.5.1 and 3.6. My machine
does not have much disk space left, so I switched TMPDIR to the
network drive. But clang then failed, like this:

$ cat x.c
#include 
int main(int ac, char *av[]) { puts("hello world"); return 0 ; }
$ mkdir /cygdrive/t/tmpdir
$ TMPDIR=/cygdrive/t/tmpdir clang x.c
error: unable to open output file '/cygdrive/t/tmpdir/x-01564d.o':
  'Operation not permitted'
1 error generated.

/cygdrive/t/tmpdir/ is a clean dir.
/usr/bin/touch /cygdrive/t/tmpdir/dummy works without problems

How can I debug this further?

Dan
-- 
Dan Shelton - Cluster Specialist Win/Lin/Bsd

-- 
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

Re: ls/stat on OneDrive causes download of files

[Corinna Vinschen via Cygwin]

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