Bugs item #3295526, was opened at 2011-04-30 17:41
Message generated for change (Comment added) made by cwilso11
You can respond by visiting:
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: MinGW Installer
Submitted By: Charles Wilson (cwilso11)
Assigned to: Keith Marshall (keithmarshall)
Summary: mingw-get remove + read-only files = fail
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.
See this report
Relevant bits quoted below:
> 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.
I think this is a bug in mingw-get's 'remove' operation. If it can create the file, when running as user A, then it should be able to delete the same file, when running as that same user A. I think mingw-get should be modified to check if a to-be-removed file is "read only" and remove the read-only attribute before trying to delete it. Only if THAT sequence fails should it report a problem to the user.
>Comment By: Charles Wilson (cwilso11)
Date: 2011-05-01 14:47
About mingw-get install + implicit chmod: "I don't plan to change it." I
agree. mingw-get should retain, if at all possible, whatever attributes the
tarball specifies, when unpacking/installing a component.
About "original package maintainer [choosing] to schedule any files to be
marked as read-only" Don't look at me. That's just what the basic perl
installation does -- I'd have to manually chmod u+w after installation (bad
idea, because I can't do -R as the files are intermingled, after
installation, in the "real" /usr tree (since perl !=
DESTDIR/reassign-$prefix) with non-package files. I do have a list of all
files to be packaged, so I could chmod u+w one at a time...but why? (I
could also patch the various makefiles -- AND module MakeMaker -- to use
644 and 755 where it currently uses 444 and 555 but again: why? Perl is
what it is, and there's nothing inherently WRONG about installing readonly
Perl is doing this on purpose. It does it on cygwin and unix. But
cygwin's setup.exe and (e..g) Fedora's rpm can manage to uninstall "read
only" files, because they are run under a user with sufficient privileges
to do so. Just like mingw-get should at least attempt to make remove()
work, on uninstall, by chmoding u+w -- if the attempt fails, well then, the
user obviously didn't have sufficient privileges. Same behavior as on
cygwin or linux.
Now, you've already agreed with that, with reservations, but I just wanted
to expand/explain the argument. Concerning your reservations about
"cavalier treatment" -- well, realistically, that's why users should be
careful when running ANY installer/uninstaller, on ANY platform: the app
will assume it owns and has full control over of all files it (previously)
installed, and WILL remove them, regardless of "permission bits" --
assuming it has sufficient privileges. That's just the way
No real hurry on the release; we have a workaround already posted on the
Comment By: Keith Marshall (keithmarshall)
Date: 2011-05-01 13:22
I did notice this, when it arose on the ML.
My first thought was that mingw-get never calls chmod(2), so how were the
files being set read-only in the first place? I had to go back and review
my original code, to confirm that the mode bits from the tarball file
header are indeed passed in the creat(2) call, which prepares to save the
extracted file; of course, this has the effect of an implicit chmod() on
close(). I think this is the correct behaviour; I don't plan to change
Now, the next thing which surprised me was that the original package
maintainer would choose to schedule any files to be marked as read-only on
installation. I presume he/she must have some good reason for making that
choice, but perhaps that should also bring with it a responsibility for
providing a pre-remove script, to clear that attribute so that a clean
removal is supported.
Okay, I'm kind of playing Devil's Advocate with that preceding statement.
Obviously, it is moot because mingw-get doesn't (yet) provide a capability
for running pre-remove scripts. The real issue is that I hadn't
anticipated having to deal with read-only package content, so the remove
function simply calls unlink(2), thus having the effect of "rm foo", where
perhaps "rm -f foo" would be preferred. (The Devil's Advocacy relates to
the desirability of such a cavalier treatment of a file which the package
maintainer considered precious enough to mark as read-only).
That said, it is a trivial change to add a chmod(2) call, immediately
preceding unlink(2), in pkgunst.cpp's pkg_unlink() function, so forcing the
"rm -f foo" behaviour. I've already prepared that, in my sandbox, so I
could push out a patch release just as soon as I can find time to update
the release notes accordingly.
You can respond by visiting: