GP SoftwareTwitter
Opus FAQsManualCommandsObjects

Can Opus Run An Admin Powershell Command?


Lately I’ve been having problems mounting any .iso file within Windows 10. What I have to do is to run an Admin Powershell command that removes the sparse flag from the .iso before it will mount. This now happens with all .iso files, and gets tiresome to have to run that command manually each time. I was wondering if it would be possible to have Opus set up with a button that would open an Admin Powershell, then run the command of –

fsutil sparse setflag “C:\whole\Path\To\The\File.iso” 0

Where the string of “C:\whole\Path\To\The\File.iso” would be replaced with the path of the selected .iso file in the active lister.

Is this possible with Opus?? TIA


fsutil is a normal command so it shouldn’t even need powershell.

Just put the command in a button with @admin as the first line of the button to make it run the command elevated.

Use {filepath$} to insert the selected file path.

fsutil sparse setflag {filepath$} 0


Thank you, Leo! I don’t have an ISO file that needs that flag set at the moment, but I have made the button using the provided code, and next time I need to apply the command, I’ll try the button, then update this thread with the result.

I really appreciate the support and fast reply!


UPDATE: I went ahead and grabbed another .iso file, then selected it and used the new button, and it works flawlessly!

Outstanding, many thanks!!!


Why are the files ending up flagged as sparse anyway? That’s not normal. It’s a pretty niche flag which is rarely used by anything, and only useful for huge files with lots of empty data (all zeros) inside, which shouldn’t include many isos.


I’d very much like to know the answer to that question also. I’ve never had that issue before, until about 2 months ago. It now happens no matter what the size of the iso file is. I’ve spent probably 2 hours searching the web for an answer as to why it happens. The closest I’ve come to an answer is that it seems to be happening to many people since mid-2017, but no one really knows why. Some chalk it up to a Windows Update, but I have never installed that particular update, so it doesn’t apply to me.

The two consistent answers to the problem are to either run that command in an Admin Powershell, or copy the iso file to somewhere( read anywhere) else, and then all is good again and it will mount. Sometimes I just have to throw up my hands and chalk it up to another MS mystery…


I wonder if the P (sParse) attribute is set on the directory the iso files are first being saved into? They might inherit the attribute. (Although everything I’ve read so far, and from what I can remember, suggests the only way a sparse file is created is if the thing that creates it explicitly requests it, and there’s no inheritance of it from the parent folder.)

This post suggests it might be something Acronis backup tools do:

Apparently libtorrent, used in some downloading tools, also does/did it:


I checked the attribute on the directory I usually put iso files into, and it’s not got the P set. However, the issue happens no matter what directory the iso files get saved into. It’s just a weird quirk that recently started happening.

I don’t use Acronis, and my downloading tool has not been updated or changed in about a year, so for me, those wouldn’t be the cause. If it were just me this is happening to, I would seriously think it was a system problem, or a particular program I used causing the issue, but it happens to many people, according to what I read on the web.

The specific problem is that when an iso file is double clicked, or mounted via the context menu, this message always pops up “Make sure the file is an NTFS volume and isn’t an compressed folder or volume”. It does seem to be a somewhat prevalent problem for many folks.


The thing in libtorrent that sets the sparse attribute seems to date back to 2015.

Something must be setting the attribute, and it’s most likely to be the thing creating the files.

It’s probably been happening for years but most things don’t mind if the attribute is set or not, so it didn’t cause any problems, until the ISO mounting tool in Windows started to have problems with it.


Yes, I agree that ‘something’ is setting that attribute, but as to exactly what… well it remains a mystery. I’d like to narrow it down to the thing that is creating the file, but I get the same result no matter if I use my browser to download the file, or if I use a torrent program to download the same file, or if I use a download accelerator to download it.

I’ve been dealing with this issue for a couple months now, and tested downloading iso files different ways, but they all give the same resulting error message when double-clicked.

And as mentioned, a quick web search will reveal that other people are having the same problem.

You did hit the nail on the head when you said the ISO mounting tool in Windows is the main source of the error message. If I used, say Daemon Tools Lite or PowerISO to mount the iso files I download, then they will mount without any error message at all. Only happens when using the native ISO mounting tool from MS.

Having said all that, I now have a quick and painless way to get those troublesome iso files in shape to be mounted by Windows, thanks to your help in creating that button. If only everyone used Opus, then we could publish this as a legit ‘quick cure’ on the web for all to take advantage of! :slight_smile:


Oh, that is strange. Could be something that hooks file creation, but it’d be a really weird thing to do. Maybe there is a way for it to be set as the default for the whole disk. It’s such a rarely used thing that there probably isn’t much knowledge of it. (I think it was traditionally for tools dealing with really huge amounts of mostly zero data, which is quite niche.)

Is the attribute set on other files saved to the same place? Maybe it’s being set on everything, but not causing problems with anything else.

I’d expect it to cause a slight performance decrease, at least with files that start out with zeros in places and then get those sections overwritten, since it’d cause them to be fragmented when the new data was written.


If you mean is that attribute set on any other kind of file type in the same place, the answer is no. It only happens with iso file types…

Yes, very strange indeed!