"Permission denied" when installing MikTeX 2.7 (V3.0.14 X32)

[Guest]

[kronda]

I faced the problem with installation of MikTeX 2.7 on Windows XP SP2 32bit. This installation involves extracting a huge number of files to the their final location on my hard disk. I received "Permission denied" error from the installer on different files (I tried the installation many times, on each attempt it stopped on another file with this error). However, it was also a .exe file although most of the files copied are not .exe. This lead to me to the idea that it is some "advanced security feature checking .exe files written to the disk and that it is some problem with this feature). I've done this installation on many computers before and have never had this problem (there was no Comodo on any of these computers). I tried to play with CFP settings (especially with Defense+ settings, even tried to completely disable the firewall and Defense+ but still the same). Finally I uninstalled Comodo, restarted and the installation went smoothly on the first try. So I guess it is of problem Comodo.

CPU: C2D T7200 (Thinkpad T60p)
Utilities running: AVG 7.5 Free edition, Lenovo Thinkvantage and Thinkpad related utilities
I did not modify any advanced settings of the firewall or Defense+

[ApolloX]

I can confirm this bug on my system as well.

Ultimately, the firewall is nice but it tries to do too much.  I'm going to uninstall since this type of unclassified side effect is a show stopper to me.

[BigMike]

After disabling Defense+ completely (in the Defense+ settings) and doing the required reboot of the system, I was able to install MiKTeX without problems.

[ApolloX]

I had Defense+ completely turned off before doing the first install and it didn't work.

I actually had to uninstall the entire program to get it to work.  Either way, this is a bug someone should fix.  I'm back to Zone Alarm for now.  I don't like the idea of Comodo breaking a process that should work (doesn't even use Internet) without so much as a notification/warning to correct it.

[kronda]

I agree with ApolloX - what's the point of having a feature (I'm talking about Defense+) which must be turned off (in some tricky way requiring reboot) to allow me to use my computer in a way I need and like? I think this is a bug in Defense+ (when in training mode I would expect some kind of dialog asking for permission...).

[BigMike]

Sure, it's an issue, which shouldn't happen.
I just wanted to say - for people having the same issue - I was able to install MiKTeX without uninstalling the complete application.

It's not so tricky - I meant, it didn't work, when I set the Defense+ protection level to disabled via the tray icons right click menu.
But, open the Application window, switch to "Defense+", select "Advanced" open "Defense+ Settings" and check "Deactivate the Defense+ permanently (Requires a system restart)", apply the settings, reboot and now it worked for me...

After installing MiKTeX you can enable Defense+ again - if you like

[ApolloX]

I think the point we're all trying to make is that you shouldn't need to turn Defense+ off in order to install a program.  At the very least a warning message should appear alerting you of the issue and allowing you to bypass it.

On top of that, there's absolutely no reason you should need to reboot to turn Defense+ off.  There is an off switch available in the program, and selecting it should "turn it off" rather than "turn part of it off".  It means Defense+ spawns processes that it cannot control or stop.

All and all, it brings to light some very serious issues:

• Defense+ blocks user-initiated actions without informing you
• Defense+ requires a reboot to truly be turned off

In my case, I had to uninstall to get it working.  As I said, its show stopper for me.  I use my computer for software development and I'm afraid of what Defense+ might do while executing code given these realizations.

[Little Mac]

I don't see in any of the posts if any of you with this issue tried using the built-in Installation Mode for D+.  I'm interested to hear if you did and the problem persisted anyway.

BigMike, tnx for the note about switching the D+ level via systray icon not working properly.  I just read another report that looked like it might be related to an issue with changing levels that way.

LM

[ApolloX]

I don't see in any of the posts if any of you with this issue tried using the built-in Installation Mode for D+.  I'm interested to hear if you did and the problem persisted anyway.

It's not our job to debug Comodo's software and try every possible permutation, that's what QA is for. 

We just report reproducible bugs (also QAs job but clearly QA missed this one so...)

[BigMike]

I don't see in any of the posts if any of you with this issue tried using the built-in Installation Mode for D+.  I'm interested to hear if you did and the problem persisted anyway.

Ok, first about my system:
- I'm running WinXP, SP2 (and as far as I know all other patches installed).
- I was working with Admin priviliges while trying to install MiKTeX (but I've also checked, that I had full write access to the installation directory)
- With about 10GB free space this also shouldn't be the problem
- Comodo version is 3.0.14.276
- Defense+ level is set to "Train with Safe Mode"
- Other security software is Avira AntiVir Personal Edition Classic and SpyBot Search & Destroy 1.5
- The MiKTeX installer is versioned 2.7.2882.0

What I've done:
After downloading the MiKTeX installer, you can select if you want to install MiKTeX from an online repository or if you want to download all packages to your hard disk to get a local install repository.
I selected to download all available packages which results in a about 610 MB folder containing 1542 files. This works without any problems and Defense+ works as expected.

After that I started the local installation, selected in the Defense+ dialog that I'm running an "Installer or Updater" and switched to the installation mode as proposed.
Then I selected that I just want to install the basic MiKTeX system.
The installation seems to work fine at the beginning, but ends up with an error, that a file could not be created. I tried several times and the filename differs.
Then I tried to disable Defense+ via tray icon, which ended up with the same error.

Then I remembered the option to disable Defense+ completely and tried this.
This time the installation worked fine. (after disabling Defense+ via tray I didn't reboot, I thought this skips simply the checks while the other option unloads the whole Defense+ drivers...)

With the basic installation, you get a folder containing about 10000 files in 465 subfolders.
You can get MiKTeX here if you need to run own tests - it's open source

[Little Mac]

It's not our job to debug Comodo's software and try every possible permutation, that's what QA is for. 

We just report reproducible bugs (also QAs job but clearly QA missed this one so...)

The point of my query is that it's not a bug if you did not switch to Installation Mode prior to running the install routine.  At that point, the HIPS module (ie, Defense +) is merely doing what it's supposed to do - protect your system from unauthorized changes.

I'm not slamming anyone or asking any user to debug the software (keep in mind I'm a volunteer user myself, not a Comodo employee); simply trying to ascertain the process that was used to attempt installation.

After that I started the local installation, selected in the Defense+ dialog that I'm running an "Installer or Updater" and switched to the installation mode as proposed.
Then I selected that I just want to install the basic MiKTeX system.

The switch to Installation Mode should really occur prior to starting the installer routine.  If you've already started the installation and then switched, it may already be attempting to access protected files in a way that is denied by default (image execution and such).  I know it would seem that it shouldn't make a difference, but that may depend some on what/how the installer tries to operate; software gets more complex every day, and the installations along with it.

In all of this, the more detailed and reproducible steps that can be supplied to Comodo, the better their chances of ironing out any bugs that exist (which is true with all software).

LM

[BigMike]

The point of my query is that it's not a bug if you did not switch to Installation Mode prior to running the install routine.  At that point, the HIPS module (ie, Defense +) is merely doing what it's supposed to do - protect your system from unauthorized changes.

No, even if you're not in Installation Mode, it's a bug in my opinion, because you've granted all demanded rights, and when the installation fails you get no hint, that Defense+ caused this. If Defense+ would work like it should, you'd get another popup asking, if you want to allow the write access or not.

The switch to Installation Mode should really occur prior to starting the installer routine.  If you've already started the installation and then switched, it may already be attempting to access protected files in a way that is denied by default (image execution and such).  I know it would seem that it shouldn't make a difference, but that may depend some on what/how the installer tries to operate; software gets more complex every day, and the installations along with it.

I think this can't be the reason in this case, because the switch to the installation mode is definitely before starting the extraction & copy process.
Also the installation seems to run fine and some of the files are extracted and copied without any problems.

[jp10558]

I don't know that this is a problem with Comodo specifically. I've had the same described problem with the MikTex installer before I ever even heard of Comodo. I've definately had it on PCs without Comodo installed, that never had Comodo installed; and it did the same thing, seemed like it was installing, then got an error about halfway through - and it was a different file each time.

Might want to take a look at the installer also.

[Munemasa Katagiri]

I have a simmilar problem. If I turn off Comodo to install something without messages I have my permissions denied.

[Tags:]