Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Message-Id: <5.1.0.14.2.20020408191101.024b9ea0@pop3.cris.com> X-Sender: rrschulz AT pop3 DOT cris DOT com Date: Mon, 08 Apr 2002 19:55:43 -0700 To: "Andrew Chang" , "Ivan Dobrianov" , From: Randall R Schulz Subject: Re: tar won't restore permissions Cc: In-Reply-To: <000701c1df64$9d0070e0$ca00660a@etp2> References: <3CB23EF3 DOT 1040504 AT cornell DOT edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Oy. There's nothing wrong with file modes in Cygwin (or Cygwin's port of "tar"), if you know how to use them and how they're implemented. There are usually some few irreducible discrepancies introduced by an emulation environment, and in Cygwin's case, POSIX file mode emulation is one of the user-visible "seams" between the two environments. So... To get the best results: Use NTFS (whenever possible and for more reasons than file permissions...). Put "ntsec" (_not_ "ntea") in your CYGWIN variable and make sure it's there _before_ the first launch of any Cygwin application. Using system-wide environment variables is a good way to accomplish this. Or, at least, user-wide environment variable, assuming you're not using Cygwin-based services that will launch before the user account that puts "ntsec" into $CYGWIN logs in. Note that it is simply impossible to use any Cygwin-based application or script to usefully add "ntsec" (or "ntea") to the environment, since by the time it could possibly do so, the Cygwin DLL has already loaded and consulted $CYGWIN. If you need file permissions in Cygwin and you must use FAT file systems, you can include "ntea" in $CYGWIN, but be prepared for the large database file required to hold the auxiliary permission information. Since "ntea" enables a Cygwin-local record of POSIX permissions, you should not be surprised that its effects are not visible outside the Cygwin environment. Note, also, that FAT has minimal intrinsic file permissions, so Windows is not ever going to accurately reflect Cygwin-emulated POSIX permissions. Contrast this with "ntsec" on NTFS volumes. In this case, Cygwin is _translating_ between POSIX file modes and Windows access controls. In this case the fidelity of POSIX mode emulation is much greater and since it relies on the NTFS built-in access controls, the overhead of recording these modes is minimal. Randall Schulz Mountain View, CA USA At 18:19 2002-04-08, Andrew Chang wrote: >FYI... I am confirming this bug, I have to use my own version of tar to >get BitKeeper to pass regression test in the cygwin env.. ( I forgot what >my hack was , but probably similar) > >Andrew > > >----- Original Message ----- >From: "Ivan Dobrianov" >To: >Cc: ; >Sent: Monday, April 08, 2002 6:08 PM >Subject: Re: tar won't restore permissions > > > > Ok, I posted this question more than a year ago ... and the problem is > > still present in the latest Cygwin builds: > > > > tar xpvf myArchive.tar > > > > will not restore read-only permissions, i.e. files with r-- perms will > > get rw- permission when restored!!! I am seeing this on Win NT, 2000, > > and XP on FAT32 and NTFS with and without setting $CYGWIN to ntea or > > ntfs. This used to work right in the days of B20. > > > > I. To see the bug: > > 1) copy the follwing text to a file called "demo" > > ----------------------------------------------------- > > echo " " > > > > [ -d tar_bug ] || mkdir tar_bug > > cd tar_bug > > rm -rf * > > > > cat > myFile< > qwerty > > EOF > > > > chmod 444 myFile > > ls -l myFile > > > > tar cvf myArchive.tar myFile > > tar tvf myArchive.tar > > > > sleep 2 > > > > mkdir untarred > > cd untarred > > tar xpvf ../myArchive.tar -U > > > > ls -l > > -------------------------------------------------------- > > 2) Do: > > sh demo > > > > 3) I get the follwing output: > > -------------------------------------------------------- > > -r--r--r-- 1 administ None 8 Jan 20 11:55 myFile > > myFile > > -r--r--r-- administrator/None 8 2001-01-20 11:55:14 myFile > > myFile > > total 0 > > -rw-r--r-- 1 administ None 8 Jan 20 11:55 myFile > > -------------------------------------------------------- > > > > *** Note that myFile is writable in the end! *** > > > > NOTE: Yes, if you "CYGWIN=ntea" under NTFS, the problem _SEEMS_ to get > > fixed, but upon inspection, with say Explorer, it turns out the file is > > still writable - the problem is just being masked! > > > > II. The fix. > > > > Well, I have a tweaked version of tar-1.13.19-1 which seems to work > > fine. Here is the hacky patch of extract.c that does the trick > > -------------------------------------------------------- > > ~/tar_fix > diff extract.c_DUP_00 extract.c > > 125a126,127 > > > /* printf ("File: %s\n", file_name); */ > > > > > 135c137,139 > > < if (permstatus == ARCHIVED_PERMSTATUS > > --- > > > /* Ivan says: for whatever reason the caller THINKS the mode > is ok, > > > but it is not, at least under Win NT w/ cygwin */ > > > if (0 && permstatus == ARCHIVED_PERMSTATUS > > 158a163,164 > > > > > > /* printf ("File: %s -> mode: %o\n", file_name, mode); */ > > ~/tar_fix > > > -------------------------------------------------------- > > > > I don't know if this is the "right" way to fix the problem - probably it > > is not! I'll leave it to more knowledgeable people to do the real thing > > ... or point the workaround that has been eluding me for that past > > year and more :-) -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/