From: Wayne S. <ws...@bi...> - 2004-02-18 18:23:01
|
I have noticed that the MSYS 'tar' doesn't seem to restore permissions correctly. $ touch f $ chmod 444 f $ ls -l f -r--r--r-- 1 wscott Administ 0 Feb 18 13:13 f $ tar -cf TAR f $ rm -f f $ tar -xf TAR $ ls -l f -rw-r--r-- 1 wscott Administ 0 Feb 18 13:13 f $ tar -xpf TAR $ ls -l f -rw-r--r-- 1 wscott Administ 0 Feb 18 13:13 f Any idea why that doesn't work? -Wayne |
From: Wayne S. <ws...@bi...> - 2004-02-18 18:42:24
|
From: Wayne Scott <ws...@bi...> > I have noticed that the MSYS 'tar' doesn't seem to restore permissions > correctly. A guy locally says that old versions of Cygwin used to have the same bug... -Wayne |
From: Earnie B. <ea...@us...> - 2004-02-19 11:53:51
|
So was it Cygwin or tar that was fixed? If Cygwin, applying an appropriate patch to MSYS would be useful. If it was tar, then some future release will contain the newer version of tar. Earnie. Wayne Scott wrote: >From: Wayne Scott <ws...@bi...> > > >>I have noticed that the MSYS 'tar' doesn't seem to restore permissions >>correctly. >> >> > >A guy locally says that old versions of Cygwin used to have the same >bug... > >-Wayne > > >------------------------------------------------------- >SF.Net is sponsored by: Speed Start Your Linux Apps Now. >Build and deploy apps & Web services for Linux with >a free DVD software kit from IBM. Click Now! >http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click >_______________________________________________ >Mingw-msys mailing list >Min...@li... >https://lists.sourceforge.net/lists/listinfo/mingw-msys > > > -- http://www.mingw.org http://sourceforge.net/projects/mingw https://sourceforge.net/donate/index.php?user_id=15438 |
From: Wayne S. <ws...@bi...> - 2004-02-19 13:46:48
|
From: Earnie Boyd <ea...@us...> > So was it Cygwin or tar that was fixed? If Cygwin, applying an > appropriate patch to MSYS would be useful. If it was tar, then some > future release will contain the newer version of tar. I would suspect it is the DLL. I have seen several problems releated to permissions. - tar doesn't extract permissions right for real-only files - chmod unable to change permissions (but not always, and I don't have a simple testcase yet) - mkdir -p A/A/A/A (I suspect this is releated, but might be totally different) Can anyone reproduce the tar and mkdir failures? They are easy to test. I have already had several examples of tar getting segfaults, but haven't put together a testcase yet. I might get around to working on these soon. Is it documented anywhere where you diverged from the Cygwin tree? Did you copy of CVS tree or just import into a clean repository. Unless this information is recorded outside of CVS, this history is very difficult to reproduce. I want to be able to examine exactly what was changed to make the MSYS dll and what has changed in Cygwin since then. BTW: Do you guys use the bug tracking facilities of Sourceforge, or should I just report problems here. -Wayne |
From: Prof A O. (T. A. Chief) <chi...@bi...> - 2004-02-19 14:11:09
|
On 19 Feb 2004 at 8:41, Wayne Scott wrote: > From: Earnie Boyd <ea...@us...> > > So was it Cygwin or tar that was fixed? If Cygwin, applying an > > appropriate patch to MSYS would be useful. If it was tar, then some > > future release will contain the newer version of tar. > > I would suspect it is the DLL. > > I have seen several problems releated to permissions. > > - tar doesn't extract permissions right for real-only files > - chmod unable to change permissions (but not always, and I don't > have a simple testcase yet) > - mkdir -p A/A/A/A > (I suspect this is releated, but might be totally different) > > Can anyone reproduce the tar and mkdir failures? [...] I have experienced problems with tar, and have just learned to live with them. One such problem is that symlinked stuff inside tarballs don't work. I get errors such as: "Cannot create symlink to `../en/bpqstart.texi': No such file or directory". I can reproduce this every time with GPC (GNU Pascal) source tarballs. Cygwin's tar has no problem with this. Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.bigfoot.com/~african_chief/ |
From: Earnie B. <ea...@us...> - 2004-02-19 17:12:58
|
Prof A Olowofoyeku (The African Chief) wrote: >I have experienced problems with tar, and have just learned to live >with them. One such problem is that symlinked stuff inside tarballs >don't work. I get errors such as: "Cannot create symlink to >`../en/bpqstart.texi': No such file or directory". > >I can reproduce this every time with GPC (GNU Pascal) source tarballs. >Cygwin's tar has no problem with this. > > Well, MSYS doesn't support symlink emulation while Cygwin does. In this case an MSYS specific change needs to be made to copy the source of the symlink to the destination. Earnie -- http://www.mingw.org http://sourceforge.net/projects/mingw https://sourceforge.net/donate/index.php?user_id=15438 |
From: Wayne S. <ws...@bi...> - 2004-03-09 22:12:41
|
I have a fix for the 'mkdir -p A/A/A/A' bug and the bug where find won't traverse into a subdirectory that has the same name as its parent. (Unsafe caching) I sent a patch to Earnie. I am now looking at this bug. From: Wayne Scott <ws...@bi...> > > I have noticed that the MSYS 'tar' doesn't seem to restore permissions > correctly. > > $ touch f > $ chmod 444 f > $ ls -l f > -r--r--r-- 1 wscott Administ 0 Feb 18 13:13 f > $ tar -cf TAR f > $ rm -f f > $ tar -xf TAR > $ ls -l f > -rw-r--r-- 1 wscott Administ 0 Feb 18 13:13 f > $ tar -xpf TAR > $ ls -l f > -rw-r--r-- 1 wscott Administ 0 Feb 18 13:13 f > it ntsec enabled by default by MSYS? http://cygwin.com/faq/faq_4.html#SEC45 I thought it was enabled, but I see this in environ.cc: #if ! __MSYS__ #ifdef NTSEC_ON_BY_DEFAULT /* Set ntsec explicit as default, if NT is running */ if (iswinnt) allow_ntsec = TRUE; #endif #endif /* ! __MSYS__ */ Which suggests that MSYS comments out this code. When I enable that chunk of code, I get commands failing like this: m.AllocationBase 0x71000000, m.BaseAddress 0x71110000, m.RegionSize 0x6000, m.State 0x1000 c:\msys\home\wscott\tmp\bin\ls.exe: *** Couldn't reserve space for cygwin's heap (0x71110000 <0x470000>) in child, Win32 error 487 Also where in the code does it ignore the CYGWIN variable? It looks like environ_init() will read it. -Wayne |
From: Wayne S. <ws...@bi...> - 2004-03-10 18:03:30
|
From: Earnie Boyd <ea...@us...> > Yes, it is filtered out and would eventually be removed. I am not > using ntsec because that would require /etc/passwd and I don't want > that for MSYS. The fix for the problem may reside in the tar source > code or in MSYS. Create code to test the way it should work. If > that works correctly then the tar source needs adjusted else we need > to adjust MSYS. Permissions should be set without extended NT > functionality. I suspect the DLL is to blame because I have also seen this problem in simple shell scripts that create files and call chmod() directly. The chmod() get ignored. Also is MSYS intended to work on win98? The cygwin docs suggest there is no solution that works on win98 for permissions. (Just curious, I am using WinXP.) However I find I am unable to build tar from source. What is the procedure? Which compiler, MinGW or the one you include with msysDVLPR? What about include files? I saw an include of pwd.h and grp.h which appears to be from newlib. How do I set things up so these will be used? -Wayne |
From: Wayne S. <ws...@bi...> - 2004-03-10 20:29:05
|
From: Wayne Scott <ws...@bi...> > I suspect the DLL is to blame because I have also seen this problem in > simple shell scripts that create files and call chmod() directly. The > chmod() get ignored. Yes that is it. Tar is opening the file like this: fh = open(path, O_CREAT|O_WRONLY|O_BINARY|O_EXCL, 0444); but the mode argument is ignored in fhandler.cc because neither allow_ntsec or allow_ntea is set. (People on the list, forgive my thrashing as the come up to speed on how this stuff work. I just like to talk out loud so people can stop me if I say something that sounds familiar.) Ahh I see how how chmod is working. The call to set_file_attribute() doesn't do anything in msys. Only a single read-only bit is tracked and it is set by the SetFileAttributesA() function. So this is the patch to open() to make it work correctly: --- fhandler.cc 19 Apr 2003 01:03:46 -0000 1.4 +++ fhandler.cc 10 Mar 2004 19:45:21 -0000 @@ -422,13 +422,28 @@ goto done; } - /* Attributes may be set only if a file is _really_ created. - This code is now only used for ntea here since the files + /* Attributes may be set only if a file is _really_ created. This + code is now only used when not using ntsec here since the files security attributes are set in CreateFile () now. */ if (flags & O_CREAT && get_device () == FH_DISK && GetLastError () != ERROR_ALREADY_EXISTS - && !allow_ntsec && allow_ntea) - set_file_attribute (has_acls (), get_win32_name (), mode); + && !allow_ntsec) { + if (allow_ntea) { + set_file_attribute (has_acls (), get_win32_name (), mode); + } else { + /* if the mode we want has any write bits set, we can't + be read only. */ + if (mode & (S_IWUSR | S_IWGRP | S_IWOTH)) + file_attributes &= ~FILE_ATTRIBUTE_READONLY; + else + file_attributes |= FILE_ATTRIBUTE_READONLY; + + if (S_ISLNK (mode) || S_ISSOCK (mode)) + file_attributes |= FILE_ATTRIBUTE_SYSTEM; + + SetFileAttributesA (get_win32_name (), file_attributes); + } + } Earnie, please add this to your changes for -rc5. -Wayne |
From: Earnie B. <ea...@us...> - 2004-03-10 14:11:49
|
Wayne Scott wrote: >I have a fix for the 'mkdir -p A/A/A/A' bug and the bug where find >won't traverse into a subdirectory that has the same name as its >parent. (Unsafe caching) I sent a patch to Earnie. > >I am now looking at this bug. > > >From: Wayne Scott <ws...@bi...> > > >>I have noticed that the MSYS 'tar' doesn't seem to restore permissions >>correctly. >> >>$ touch f >>$ chmod 444 f >>$ ls -l f >>-r--r--r-- 1 wscott Administ 0 Feb 18 13:13 f >>$ tar -cf TAR f >>$ rm -f f >>$ tar -xf TAR >>$ ls -l f >>-rw-r--r-- 1 wscott Administ 0 Feb 18 13:13 f >>$ tar -xpf TAR >>$ ls -l f >>-rw-r--r-- 1 wscott Administ 0 Feb 18 13:13 f >> >> >> > >it ntsec enabled by default by MSYS? > http://cygwin.com/faq/faq_4.html#SEC45 > >I thought it was enabled, but I see this in environ.cc: > > #if ! __MSYS__ > #ifdef NTSEC_ON_BY_DEFAULT > /* Set ntsec explicit as default, if NT is running */ > if (iswinnt) > allow_ntsec = TRUE; > #endif > #endif /* ! __MSYS__ */ > >Which suggests that MSYS comments out this code. > > > Yes, it is filtered out and would eventually be removed. I am not using ntsec because that would require /etc/passwd and I don't want that for MSYS. The fix for the problem may reside in the tar source code or in MSYS. Create code to test the way it should work. If that works correctly then the tar source needs adjusted else we need to adjust MSYS. Permissions should be set without extended NT functionality. >When I enable that chunk of code, I get commands failing like this: > > m.AllocationBase 0x71000000, m.BaseAddress 0x71110000, m.RegionSize 0x6000, m.State 0x1000 > c:\msys\home\wscott\tmp\bin\ls.exe: *** Couldn't reserve space for cygwin's heap (0x71110000 <0x470000>) in child, Win32 error 487 > >Also where in the code does it ignore the CYGWIN variable? It looks >like environ_init() will read it. > > I can't ignore the variable completely, it is used for interprocess control when fork is invoked. However, the values for the parse_thing structure were modified so that I have it my way and not the user specified way. Earnie -- http://www.mingw.org http://sourceforge.net/projects/mingw https://sourceforge.net/donate/index.php?user_id=15438 |