Cygwin making files inaccessible?

Jay K
Mon Feb 7 05:23:53 GMT 2022

I looked at this a while. I tried various recent cygwin1.dlls as there were two ACL changes recently.
I tried building cygwin1.dll with those changes reverted, but failed to build it. 
For one thing it took me a while to find is in cocom, but that wasn't the entire problem.

Eventually.. I noticed the behavior was not the same for every file/directory/volume. Sometimes it worked ok.
Though I think the ACLs still get changed quite a bit: "full" expands to "many".
Of course it has worked plenty for me and everyone else.

Eventually I tried chmod -R 777 * and this seems to have worked.

I speculate that some "bad" Cygwin ACLs got created at some point.
 And maybe cacls wasn't deleting them?? That parts seems wierd. Maybe on directories?
Possibly due to those two recent changes, or maybe user error, I don't know.

 - Jay

From: Jay K
Sent: Saturday, February 5, 2022 12:16 PM
To: <>
Subject: Cygwin making files inaccessible? 
Cygwin making files inaccessible?
i.e. when Cygwin copies or writes to them, not random files.

C:\t>dir /s/b/a

C:\t>dir /q .

02/05/2022  04:11 AM    <DIR>          BUILTIN\Administrators .
02/05/2022  04:11 AM    <DIR>          NT SERVICE\TrustedInsta..

C:\t>cacls .
C:\t Everyone:(OI)(CI)F

C:\t>echo > 1.txt

C:\t>cacls 1.txt
C:\t\1.txt Everyone:F

C:\t>copy 1.txt 2.txt
        1 file(s) copied.

C:\t>cacls 2.txt
C:\t\2.txt Everyone:F

C:\t>del 2.txt

C:\t>uname -a
CYGWIN_NT-10.0-WOW DESKTOP-BCFUMJ4 3.3.4(0.341/5/3) 2022-01-31 19:31 i686 Cygwin

C:\t>cp 1.txt 2.txt

C:\t>which cp

C:\t>cacls 2.txt
C:\t\2.txt NULL SID:(DENY)(special access:)

           DESKTOP-BCFUMJ4\jay:(DENY)(special access:)

           DESKTOP-BCFUMJ4\jay:(special access:)


C:\t>more 1.txt
ECHO is on.

C:\t>more 2.txt
Cannot access file C:\t\2.txt

Same behavior from cygwin64.

C:\t>\cygwin64\bin\uname -a
CYGWIN_NT-10.0 DESKTOP-BCFUMJ4 3.3.3(0.341/5/3) 2021-12-03 16:35 x86_64 Cygwin


I would hope Cygwin could/would just copy the ACLs asis.
I am guessing there is some failed attempt to translate them
to an internal form and then back to NT form.

My real scenario was open/write/read, not cp.exe.

 - Jay

More information about the Cygwin mailing list