public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
From: Brian Inglis <Brian.Inglis@SystematicSW.ab.ca>
To: cygwin@cygwin.com
Subject: Re: Cygwin 3.5.1: unable to open output file '/cygdrive/t/tmpdir/x-01564d.o': 'Operation not permitted'
Date: Mon, 11 Mar 2024 10:59:02 -0600	[thread overview]
Message-ID: <36e07086-b975-416d-b2c1-a5bd208cb7de@SystematicSW.ab.ca> (raw)
In-Reply-To: <CAKAoaQ=SN7RoR78-OGogQBSzFSndhysJpgR4c-+nEzkvTqZhGA@mail.gmail.com>

On 2024-03-11 04:27, Roland Mainz via Cygwin wrote:
> On Mon, Mar 11, 2024 at 8:01 AM Cedric Blancher via Cygwin
> <cygwin@cygwin.com> wrote:
>> On Fri, 8 Mar 2024 at 03:25, Dan Shelton via Cygwin <cygwin@cygwin.com> wrote:
>>> 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 <stdio.h>
>>> 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
>>
>> I can confirm the bug, but only for the clang version linked to
>> Cygwin. clang version of MinGW does not show that error, so this looks
>> like a Cygwin bug.
> 
> I can reproduce the bug on Cygwin "CYGWIN_NT-10.0-19045
> 3.6.0-0.73.gc2310061c66a.x86_64":
> ---- snip ----
> $ cat x.c
> #include <stdio.h>
> int main(int ac, char *av[]) { puts("hello world"); return 0 ; }
> 
> $ TMPDIR=/cygdrive/t/tmpdir/ strace -o clang_tmpdir_on_nfs41fs.log
> "C:\cygwin64\bin\clang-8.exe" x.c
> error: unable to open output file '/cygdrive/t/tmpdir/x-8cb6f7.o':
> 'Operation not permitted'
> 1 error generated.
> ---- snip ----
> 
> Full strace log is at https://nrubsig.kpaste.net/ff6248c25 (I use the
> line numbers from that site below).
> 
> It seems starting with line 2949 this goes wrong:
> ---- snip ----
>    505 5069822 [main] clang-8 40295 symlink_info::check: 0x0 =
> NtCreateFile (\??\T:\tmpdir\x-8cb6f7.o)
>   3645 5073467 [main] clang-8 40295 symlink_info::check: not a symlink
>    266 5073733 [main] clang-8 40295 symlink_info::check: 0 =
> symlink.check(T:\tmpdir\x-8cb6f7.o, 0x7FFFF96E0) (mount_flags 0x4020,
> path_flags 0x0)
>    310 5074043 [main] clang-8 40295 path_conv::check:
> this->path(T:\tmpdir\x-8cb6f7.o), has_acls(1)
>    305 5074348 [main] clang-8 40295 build_fh_pc: fh 0x800027A30, dev 000000C3
>   1441 5075789 [main] clang-8 40295 __set_errno: int
> check_access(security_descriptor&, GENERIC_MAPPING&, ACCESS_MASK, int,
> bool):600 setting errno 13
>    257 5076046 [main] clang-8 40295 check_file_access: flags 0x2, ret -1
> ---- snip ----
> 
> So |build_fh_pc()| somehow fails with error 13... but I don't understand why...
> 
> And then there is this weird ACL:
> ---- snip -----
> $ ls -l /cygdrive/t/tmpdir/x-8cb6f7.o
> -rw------- 1 Unix_User+197608 Unix_Group+197121 0 Mar 11 11:00
> /cygdrive/t/tmpdir/x-8cb6f7.o
> $ getfacl /cygdrive/t/tmpdir/x-8cb6f7.o
> # file: /cygdrive/t/tmpdir/x-8cb6f7.o
> # owner: Unix_User+197608
> # group: Unix_Group+197121
> user::---
> group::---
> other::---
> ---- snip ----
> 
> /usr/bin/file, echo&&/&/usr/bin/cat can read/write that file
> ---- snip ----
> $ file /cygdrive/t/tmpdir/x-8cb6f7.o
> /cygdrive/t/tmpdir/x-8cb6f7.o: empty
> $ echo "foo" >>/cygdrive/t/tmpdir/x-8cb6f7.o
> $ cat /cygdrive/t/tmpdir/x-8cb6f7.o
> foo
> ---- snip ----
> 
> I have no idea why clang fails in this case... I need help with this one...

For normal temp space behaviour under Cygwin, I found you have to:

chmod   -c a+rwxt 					   /cygdrive/t/tmpdir/
setfacl -m u::rwx,g::rwx,o::rwx,d:u::rwx,d:g::rwx,d:o::rwx /cygdrive/t/tmpdir/

to set the DACLs to rwx and avoid any problems.

-- 
Take care. Thanks, Brian Inglis              Calgary, Alberta, Canada

La perfection est atteinte                   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer     but when there is no more to cut
                                 -- Antoine de Saint-Exupéry


  reply	other threads:[~2024-03-11 16:59 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-08  2:24 Dan Shelton
2024-03-08  7:31 ` Cedric Blancher
2024-03-08 22:44   ` Dan Shelton
2024-03-11  7:01 ` Cedric Blancher
2024-03-11 10:27   ` Roland Mainz
2024-03-11 16:59     ` Brian Inglis [this message]
2024-04-19 23:46       ` Dan Shelton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=36e07086-b975-416d-b2c1-a5bd208cb7de@SystematicSW.ab.ca \
    --to=brian.inglis@systematicsw.ab.ca \
    --cc=cygwin@cygwin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).