It appears that mingw-get is able to install files that it cannot uninstall. This seems wrong. I think mingw-get remove should check if a file is read-only, and if so then attempt to remove the read-only flag before removing the file. Only if it fails after all of that should an error be reported to the user.
Alternatively, mingw-get install should ensure that any file unpacked has write permissions at least for the current user, regardless of the permission bits in the tarball. I think this is inferior to the first solution, because this alternative solution means there would be a difference between using mingw-get install to install a package, and untarring it manually.
> When I tried the upgrade I got a huge swarm of messages like the one
> below. I have never seen this before,
> all previous mingw and msys upgrades and installs have worked perfectly.
> mingw-get: *** WARNING ***
> failed; Permission denied
It seems this is because both the perl-5.6.1-*-bin tarball AND the new
perl-5.8.8-1-bin tarball have files like this:
-r-xr-xr-x user/group 7236 2011-04-27 00:23 bin/config_data
-r--r--r-- user/group 838 2011-04-27 00:24 lib/perl5/5.8/abbrev.pl
-r-xr-xr-x user/group 119 2010-01-30 14:41 bin/cpan
-r--r--r-- user/group 838 2010-01-30 14:35 lib/perl5/5.6/abbrev.pl
That is, inside the tarball the file is listed with no write permission. The list of such files with missing write perms is different between the two releases, but there is some overlap.
When mingw-get unpacks these tarballs, the affected file(s) are created like this:
-r-xr-xr-x+ 1 user group 7.1K Apr 27 10:10 bin/config_data
-r-xr-xr-x+ 1 user group 838 Apr 27 10:10 lib/perl5/5.8/abbrev.pl
-r-xr-xr-x 1 user group 7236 Apr 27 10:10 /bin/config_data
-r--r--r-- 1 user group 838 Apr 27 10:10 /lib/perl5/5.8/abbrev.pl
windows gui properties reports:
config_data: The Read-only attribute is checked.
Log in to post a comment.