From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from andromeda.onevision.de (unknown [212.77.172.62]) by sourceware.org (Postfix) with ESMTP id 5884A3858428 for ; Mon, 7 Feb 2022 07:50:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 5884A3858428 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=onevision.de Authentication-Results: sourceware.org; spf=none smtp.mailfrom=onevision.de Received: from [192.168.5.32] (v5515-01.onevision.de [192.168.5.32]) by andromeda.onevision.de (8.14.2/8.12.9/ROSCH/DDB) with ESMTP id 2177o1Kf015950 for ; Mon, 7 Feb 2022 08:50:02 +0100 Message-ID: Date: Mon, 7 Feb 2022 08:49:46 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 To: cygwin@cygwin.com From: Roland Schwingel Subject: Re: Cygwin making files inaccessible? Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.0 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: cygwin@cygwin.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Cygwin discussions and problem reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2022 07:50:05 -0000 Hi... I have seen similar problems on my side, but could not knock them down 100% reproducable to get a good recipe for debugging it. I got this best reproduceable if I generate a tar on linux with eg a windows .exe inside. and than untar it on cygwin. Afterwards ACLs were broken. Not every time but frequently. When using windows Explorer I got a message like "Permissions are not sorted in the correct way" (in german) when I tried to see permissions. And afterwards they have been quite strange and files where not accessable / executable. I have it with 3.x up to 3.3.4. Roland "Cygwin" wrote on 07.02.2022 08:01:33: > From: "Andrey Repin" > To: "Jay K" , cygwin@cygwin.com > Date: 07.02.2022 08:05 > Subject: Re: Cygwin making files inaccessible? > Sent by: "Cygwin" > > Greetings, Jay K! > > > 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 shilka..it 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. > > This may happen outside Cygwin tree, when initial ACL's are set in some > interesting way. > One possible solution is to tweak /cygdrive mount point to include "noacl" > flag, deferring all ACL modifications to Windows. > > (Please bottom post in this list. Thank you.) > > > > From: Jay K > > Sent: Saturday, February 5, 2022 12:16 PM > > To: cygwin@cygwin.com > > 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              BUILTIN\Administrators . > > 02/05/2022  04:11 AM              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 > > /usr/bin/cp > > > C:\t>cacls 2.txt > > C:\t\2.txt NULL SID:(DENY)(special access:) > >                     READ_CONTROL > > >            DESKTOP-BCFUMJ4\jay:(DENY)(special access:) > >                                FILE_READ_DATA > >                                FILE_READ_EA > >                                FILE_EXECUTE > > >            DESKTOP-BCFUMJ4\jay:(special access:) > >                                STANDARD_RIGHTS_ALL > >                                DELETE > >                                READ_CONTROL > >                                WRITE_DAC > >                                WRITE_OWNER > >                                SYNCHRONIZE > >                                STANDARD_RIGHTS_REQUIRED > >                                FILE_READ_ATTRIBUTES > >                                FILE_WRITE_ATTRIBUTES > > >            DESKTOP-BCFUMJ4\None:R > >            Everyone:R > > > > 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 > > > Huh? > > > 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 > > > > -- > With best regards, > Andrey Repin > Monday, February 7, 2022 9:59:12 > > Sorry for my terrible english... > > -- > 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 >