topbanner_forum
  *

avatar image

Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
  • Monday April 15, 2024, 11:43 pm
  • Proudly celebrating 15+ years online.
  • Donate now to become a lifetime supporting member of the site and get a non-expiring license key for all of our programs.
  • donate

Author Topic: The MagicRAR Drive Press Challenge  (Read 13362 times)

simonking

  • Participant
  • Joined in 2013
  • *
  • Posts: 19
    • View Profile
    • Donate to Member
  • WarningUser is banned
The MagicRAR Drive Press Challenge
« on: January 10, 2013, 01:22 PM »
MagicRAR Drive Press is an NTFS compression based, transparent full-disk compressor. As explained at http://www.magicrar.com/drive-press.html, despite being based on very safe, time-tested, and reliable NTFS compression, MagicRAR Drive Press will squeeze more space out of your computer every single time - typically three times more than Windows itself - as long as you are running Windows Vista, or a newer operating system (including Windows 7, Windows 8, and their server variants). Best of all, because MagicRAR Drive Press is NTFS compression based, you do not need to have it installed to keep accessing your files and data - your drive will work on any computer, with or without MagicRAR Drive Press! Indispensable for SSD users where space costs a premium, MagicRAR Drive Press has been optimized for performance and will even convert your drive in a fraction of the time it normally takes Windows to compress.

Take the MagicRAR Drive Press Challenge! If you can find any third party tool, or can get Windows itself, to match MagicRAR Drive Press's compression, we will give you a free license for the full MagicRAR product when you submit your claim to simon at magicrar.com. And as part of the challenge, we are giving away a fully functional, special edition of MagicRAR Drive Press for absolutely free - for one week only (as of this posting):

http://www.magicrar....drivepressdirect.exe - 1.43 MB, direct download, runs immediately without needing pre-installation.

The URL above will remain live for one week only as of this posting, and we trust you will not share the download outside of this forum. This special edition of MagicRAR Drive Press is identical to the full version of MagicRAR Drive Press as found in the full MagicRAR product, with the only difference being that it is completely free!

Find out more about what makes the full MagicRAR product unique at http://www.magicrar.com/features.html. In a nutshell:

- Plug-In Based: Easily extended to support new archive types by installing new plug-ins for them.
- Open Source: Download example plug-ins and their source code at the GitHUB repository for MagicRAR at https://github.com/magicrar. Contribute your own!
- Benchmarking: Cycle through each installed compression algorithm on your own selection of files and folders to find the smallest possible archive with a single right-click in Windows Explorer.
- So Easy, Its Magic: MagicRAR's unique shell namespace extension technology makes all supported archive types browsable in Windows Explorer like ordinary folders - with full support for copy/paste, drag/drop, and double-click to seamlessly extract/compress files.
- Outlook Integration: Directly preview compressed attachments in Outlook with the MagicRAR Outlook preview handler. Automatically compress attachments you are emailing, choosing the archive format and toggling compression on or off with a single click on the ribbon toolbar.

That's just a short list of what's available with MagicRAR, in addition to the wonderful MagicRAR Drive Press utility.

In the words of Scott Swedorski, founder of TUCOWS, and reviewer of MagicRAR: "The software is great. I am very impressed with the level of tools included with it...This is far more than just a RAR creator! What a great tool. I have used WinRAR for years and this blows it out of the water!"

We are confident you will find MagicRAR to be your new archiver of choice. Please enjoy the free edition of MagicRAR Drive Press - and do let us know if you can beat us in the challenge, it will be our pleasure to issue your free license!

- Simon King.

mouser

  • First Author
  • Administrator
  • Joined in 2005
  • *****
  • Posts: 40,900
    • View Profile
    • Mouser's Software Zone on DonationCoder.com
    • Read more about this member.
    • Donate to Member
Re: The MagicRAR Drive Press Challenge
« Reply #1 on: January 10, 2013, 01:29 PM »
Sounds like a fair offer and challenge  :up:

flamerz

  • Supporting Member
  • Joined in 2011
  • **
  • Posts: 157
    • View Profile
    • Donate to Member
Re: The MagicRAR Drive Press Challenge
« Reply #2 on: January 11, 2013, 04:11 AM »
could you explain in short the licensing terms?

license per machine, per user, what kind of activation...

thanks in advance for your offering.

simonking

  • Participant
  • Joined in 2013
  • *
  • Posts: 19
    • View Profile
    • Donate to Member
  • WarningUser is banned
Re: The MagicRAR Drive Press Challenge
« Reply #3 on: January 11, 2013, 11:01 AM »
I'm glad you asked.

Activation is by serial key paired with an email address. Activation is offline, meaning you do not need to have an Internet connection while activating. Licensing is per user.

MagicRAR itself has an inverse 30 day money back guarantee. Meaning, once you order, your credit card is not billed, but you instantly receive a serial key. You have 30 days to cancel your order - if you do so, your card will not be charged. And we trust you will remove the software from your computer and destroy the key should you decide to cancel after ordering.

f0dder

  • Charter Honorary Member
  • Joined in 2005
  • ***
  • Posts: 9,153
  • [Well, THAT escalated quickly!]
    • View Profile
    • f0dder's place
    • Read more about this member.
    • Donate to Member
Re: The MagicRAR Drive Press Challenge
« Reply #4 on: January 14, 2013, 09:32 AM »
Right, so I played around with DrivePress.

I'll have to some more testing before posting anything detailed, but my findings so far:

1) DrivePress achieves more compression than "Windows' built-in" compression, sure. But it's not at the level of NTFS compression itself (so nothing magical - DrivePress does indeed, as I proposed, simply uses DeviceIoControlFSCTL_SET_COMPRESSION)), and claiming that "Windows compression, is buggy and fails to compress a majority of your hard disk" is a blatant lie incorrect. More on this below.

2) Runtimes for Windows' default compression can't be compared directly to DrivePress, since it processes far fewer files - DrivePress would come out the loser, anyway. Futhermore, for a standard HDD, increasing the processing threads from 2 (the default) to 4 (the cores I allotted my virtual machine) from ~31 to ~34 minutes, which is to be expected given that a standard Windows installation has a whole bunch of very small files, which results in lots of random I/O... HDDs hate that.

3) I've yet to test with a single thread - that might actually yield better performance than two threads, since there'll be even less random I/O, and since the CPU usage was generally in the 1-digit ballpark, except when processing executables (hello there, Windows Defender).

4) SSDs can probably benefit from running multiple threads, since they're much better at random I/O than HDDs. But as I've already mentioned, NTFS compression on SSDs is A Very Bad Idea (except for applying it to specifically chosen mostly-static files). Filesystem stats after running DrivePress:
134067 files, 132637 compressed (98.9%)
Sizes - compressed: 12234652699, uncompressed: 18137110610 (67.5%)
Total fragments: 665541 (531474 excess frags)
Also, because of the way NTFS compression works, even if you do a defrag after compression (defrag and SSD? Ouch again!), you will end up generally suffering more compression than when dealing with uncompressed files (ask yourself how writes into the middle of a compressed file has to be handled - or go read up on how NTFS compression is implemented).



So, "Windows compression, is buggy and fails to compress a majority of your hard disk"?
Not really. Since Vista, security on Windows has been ramped up quite a bit. Lots of stuff has happened, but relevant to this discussion is file permissions. If you go look at the NTFS permissions for core stuff in Program Files, or Windows\System32\DriverStore or Windows\WinSxS you'll see that they have quite restrictive permissions - heck, even the SYSTEM Windows account (the one that normally has the most privileges) only has read-only access to WinSxS, leaving write access to the TrustedInstaller account!

Now, if you're a member of the Administrator group, and go through UAC (which DrivePress does), you can grant yourself access to those files - (which is what DrivePress does - at least it doesn't make those permissions permanent). So nothing magic here, no bugs, just temporary bypassing of Windows' security.

Is it a bad thing to do? Probably not. But it's hardly rocket science.
- carpe noctem

f0dder

  • Charter Honorary Member
  • Joined in 2005
  • ***
  • Posts: 9,153
  • [Well, THAT escalated quickly!]
    • View Profile
    • f0dder's place
    • Read more about this member.
    • Donate to Member
Re: The MagicRAR Drive Press Challenge
« Reply #5 on: January 14, 2013, 09:45 AM »
Ah yes, almost forgot this:
6. "The software probably does nothing else than force the compression flag on all files, even on those, where it would make no sense"

False. If you indiscriminately compress all files on your computer, you will actually end up with an unbootable system. Drive Press is completely safe to use and will not compress files that will jeopardize your operating system's integrity or ability to boot.

After running DrivePress, FindCompressed "Found 1008 uncompressed files in 131695 items examined." - a bit of this seemed relatively random (Vmware Tools, some WinSxS folders), Windows Defender was also untouched (I wonder if MS applies special protection to those folders?), and obviously some "heavily locked in-use files" (like registry hives) were untouched.

Also, as I previously mentioned, there's indeed some files you shouldn't compress if you want a bootable system. Those are a very small subset of the files left uncompressed by DrivePress. Searching for "ntldr" in the executable gives the following list, which makes sense:
{ "NTDETECT.COM", "ntldr", "boot.ini", "bootmgr", "BOOTNXT", "\Boot\" }
- carpe noctem

simonking

  • Participant
  • Joined in 2013
  • *
  • Posts: 19
    • View Profile
    • Donate to Member
  • WarningUser is banned
Re: The MagicRAR Drive Press Challenge
« Reply #6 on: January 15, 2013, 04:13 AM »
1) If you run MagicRAR Drive Press on Windows XP, or for example Server 2003, you will see that there is no difference in free space gains between using MagicRAR Drive Press and Windows itself to compress the drive. This is because this bug does not exist on NT 5.x OS's. It was introduced for the first time in Windows Vista, and has remained on all Windows versions (including Server editions) since.

As you have correctly discovered, a big part of this difference (though not all) is explained by the Windows shell failing to temporarily acquire and then restore permissions to protected file system areas. This is a bona-fide bug, because as you have seen for yourself, compressing these additional files is completely safe, and was already a matter of fact on older Windows versions. There is nothing preventing Windows Explorer from doing exactly what MagicRAR Drive Press is doing for you here; in fact that is exactly what it should have been doing in the first place.

2&3) You would need an SSD to see this for yourself, but no - these claims of yours are still false. Because most modern SSDs have an incredibly high number of IOPS, and because NTFS compression has very low CPU overhead as you have correctly determined, it is possible to dramatically accelerate the conversion process of an entire hard disk by maxing out the worker threads available.

In my experience, one CPU core (even if it is only an HT core) can handle two NTFS compression worker threads. So this is why the MagicRAR Drive Press Options Window offers to create up to double the number of worker threads as you have CPU cores available. Whether or not you use all of these depends on how fast your hard drive is. I would not recommend more than two-three threads with a mechanical drive, based on how fast it is (say 1 thread for 5400 rpm or slower; 2 for 7200 rpm or slower, and 3 if you have a 10k rpm drive - maybe 4 if you have a 15k rpm drive).

With an SSD, you can go really crazy though! For example Intel 320 series 600 GB SATA II SSDs seem to be able to handle 12 threads just fine. Now, even with Windows having a lot less files to compress, you can imagine that with 12 times the firepower, MagicRAR Drive Press just comes out on top of the speed race: Assume that Windows has about 1/3rd the job to do (roughly accurate, per our claim that MagicRAR Drive Press triples Windows compression). If MagicRAR Drive Press has to do 3 times more work, but can do it 12 times faster; this still works out to about 4 times faster globally. So this is a happy case of you having your cake and eating it too: You save three times more space, and four times faster at that! Does that sound like well built software to you?

4) False again. NTFS compression does increase fragmentation on hard drives, and this has nothing to do with MagicRAR Drive Press, since it is an innate disadvantage (and quite probably the only one) of using NTFS compression. However, a fragmented hard drive has absolutely zero impact on an SSDs performance. Fragmentation slows down your read/write speeds, because the drive head is constantly waiting for the platter to spin to all kinds of different places when reading/writing data. It is exactly this overhead that SSDs do not have, and that is why they feel so fast.

Because an SSD can read from/write to all parts of the drive at the same time (think of a hard disk platter rotating at infinite speed), that is why fragmentation is of absolutely no consequence for SSDs - be it NTFS compression induced, or the "normal" fragmentation that happens on NTFS inevitably. There is no delay, because all areas of disk are equally accessible at all times. In fact, this random access speed boost is the main reason why SSDs feel so fast. If you compare sequential access speeds between SSDs and mechanical drives, they're not too far apart. There's certainly no 10-20 times difference in those peak read speeds. It's only when you start comparing random access speeds that SSDs are many orders of magnitudes faster than mechanical drives. That is the main reason why its such a thrill to use them - you can keep throwing more and more work at the computer, and it just won't slow down.

A few closing points:

a. Do NOT attempt to manually acquire file permissions just to be able to compress them. Doing this will create a huge security hole on your system (one that MagicRAR Drive Press does not create, because it restores all permissions as has been confirmed in this third party report). And because virtually all areas of your system folders have unique permissions, it will be near impossible for you to manually restore permissions correctly. You may find yourself unable to install software on your computer, for example, if you mix up permissions during the restore phase.

Again, this is why properly speaking, this is considered to be a bug in Windows - one that is practically impossible to workaround manually without third party software that does the job automatically.

b. There will always be some files/folders that would be locked by the system/applications, and as such incompressible. If there is demand for it, we could also automate the conversion of those parts by building a boot time version of MagicRAR Drive Press - however, in my research, the additional space savings would be negligible.

So while the MagicRAR Drive Press Challenge technically remains unmet, I would be delighted to give f0dder a free key for the full MagicRAR 8.0 product, in appreciation of his time. It's the least I could do to thank for an open mind.

f0dder

  • Charter Honorary Member
  • Joined in 2005
  • ***
  • Posts: 9,153
  • [Well, THAT escalated quickly!]
    • View Profile
    • f0dder's place
    • Read more about this member.
    • Donate to Member
Re: The MagicRAR Drive Press Challenge
« Reply #7 on: January 15, 2013, 07:27 AM »
1) If you really belive it's a bug that the Shell doesn't temporarily remove protection of critical system files, you should file a but report on MS Connect, instead of making spurious claims in your marketing material - I'm pretty sure this is a by-design decision from Microsoft. I do agree it's probably harmless to compress those files, but calling a security feature a bug is misleading marketing, IMHO. And you deliberality keep your wording vague enough (combined with your "three times smaller", which is obviously only valid if there's not much else on the disk than Windows) to give the impression that the "bug" would be somewhere else (like, the core NTFS compression routines). THIS is why I'm pursuing this aggressively - you're using snake-oil salesman tactics. Which is a shame, since you obviously do get a better compression rate (and you really do ought to warn users that you're doing it by messing with critical OS files).

2 & 3) There's nothing wrong with what I've stated here. I do acknowledge in SSD speedup in #4, but for obvious reasons there's no way in hell I'll be NTFS compression any of my SSDs. The HDD backing my VM disk image is a 10k rpm velociraptor. I plan on running a single-threaded DrivePress later today to compare with the 2-thread version.

4) first, again my problem with compression on an SSD isn't the speed hit caused by fragmentation (it's several scores lower than the speed hit on a HDD, but it's still real) - it's (to some degree) the reduced speed and hindered wear-leveling on (at least, but probably not limited) drives with SandForce controllers, and (to a fairly large degree) the heavily increased amount of block erases caused by how NTFS compression is implemented. Having NTFs compression on often-modified files approaches suicidal tendencies for an SSD.

Because an SSD can read from/write to all parts of the drive at the same time (think of a hard disk platter rotating at infinite speed), that is why fragmentation is of absolutely no consequence for SSDs - be it NTFS compression induced, or the "normal" fragmentation that happens on NTFS inevitably. There is no delay, because all areas of disk are equally accessible at all times.
This is patently wrong - take a look at some benchmarks. For instance, the 120GB Intel 510 drive does ~50MB/s for 4k random reads, whereas it does ~380MB/s for 128kb sequential reads (4k sequential would be slower, but should still be quite a lot faster than the random reads). You'll notice that it does 4k random *writes* faster, which is obviously because the drive has internal cache and can do (sequence-optimized) writes at leisure - and some of the other drives handle this even better.

a. Do NOT attempt to manually acquire file permissions just to be able to compress them. Doing this will create a huge security hole on your system (one that MagicRAR Drive Press does not create, because it restores all permissions as has been confirmed in this third party report).
This is very good indeed - the way you handle the permissions is something to give credit for. I didn't look too closely at the code, but it seemed like you even throw in exception handling to do the permission-restore? You do leave files potentially vulnerable during the compression process... not much of a real-world problem, but could be reason enough for Microsoft consciously choosing not to do it. I still feel it wrong to classify the behaviour as a bug.

b. There will always be some files/folders that would be locked by the system/applications, and as such incompressible. If there is demand for it, we could also automate the conversion of those parts by building a boot time version of MagicRAR Drive Press - however, in my research, the additional space savings would be negligible.
Agreed.

So while the MagicRAR Drive Press Challenge technically remains unmet
Ho, humm, you still chose not to properly address any of the points of the original thread, most of which I showed to be clearly true. As I see it, only the points regarding interactions with SSD speed/lifetime can be debated... and for those points, I indeed do believe that I'm correct; what can be debated is to which degree lifetime and performance will be affected. For the current crop of SSDs, I definitely wouldn't do gung-ho NTFS compression, and I would recommend people against it.

Selective compression of static files would be fine, though. I wonder if it would make sense to apply compression on the files on another (and preferably HDD) partition, then move the files to the SSD target? I haven't tested, but it might result in less fragmentation of the target files.

Oh, and one last thing: your progress bars are severely bugged - they reached 100% several minutes before the actual operation was done (bugged both in analyze as well as compress phase). Looks like you use Delphi, and I haven't touched that since Delphi2, so dunno if there's limits on it's current/max values... but iirc the win32 controls are/were clamped to pretty low values, meaning you definitely shouldn't be using currentBytes/maxBytes - or even currentNumFiles/maxNumFiles for modern filesystems.
- carpe noctem

wraith808

  • Supporting Member
  • Joined in 2006
  • **
  • default avatar
  • Posts: 11,186
    • View Profile
    • Donate to Member
Re: The MagicRAR Drive Press Challenge
« Reply #8 on: January 15, 2013, 07:40 AM »
Oh, and one last thing: your progress bars are severely bugged - they reached 100% several minutes before the actual operation was done (bugged both in analyze as well as compress phase). Looks like you use Delphi, and I haven't touched that since Delphi2, so dunno if there's limits on it's current/max values... but iirc the win32 controls are/were clamped to pretty low values, meaning you definitely shouldn't be using currentBytes/maxBytes - or even currentNumFiles/maxNumFiles for modern filesystems.

Could also be C++ builder.  And yes, there are limits for the reason you stated.  It's an int (16 or 32-bit depending on the version of comctrl32.dll [ref].

f0dder

  • Charter Honorary Member
  • Joined in 2005
  • ***
  • Posts: 9,153
  • [Well, THAT escalated quickly!]
    • View Profile
    • f0dder's place
    • Read more about this member.
    • Donate to Member
Re: The MagicRAR Drive Press Challenge
« Reply #9 on: January 15, 2013, 07:44 AM »
Could also be C++ builder.
Ah yes, that can use the VCL (and other Delphi components) as well - didn't look closely, just saw some .pas references.

And yes, there are limits for the reason you stated.  It's an int (16 or 32-bit depending on the version of comctrl32.dll [ref].
That reference mentions 64k limit - I wonder if comctrl uses signed or unsigned integers? It's been ages, but I seem to recall doing 32k clamping?
- carpe noctem

simonking

  • Participant
  • Joined in 2013
  • *
  • Posts: 19
    • View Profile
    • Donate to Member
  • WarningUser is banned
Re: The MagicRAR Drive Press Challenge
« Reply #10 on: January 15, 2013, 09:03 AM »
If the progress bars reached completion only a few minutes off, I am glad to hear that - it is very difficult to get them working properly, and a few minutes on hour/day long tasks is a very reasonable rounding error that I'm happy to live with.

I realize you personally may not test this, but if you actually test MagicRAR Drive Press on a production system (by running it after letting Windows do the initial work), you will still see two to three times the space savings compared to Windows itself. This is because Windows misses a majority of the files that are completely safe to compress (and were included in previous Windows versions). Yes, those files that Windows fails to compress do make that big of an impact.

And actually, MagicRAR Drive Press somewhat under-reports the space it has freed by about 30% - this is because after a compression call to Windows has been made and it returns success, the compression (and space savings) still happen in the background for a few more minutes. It was not possible to definitively determine when Windows would be ultimately finished with compressing a file, so the under-reporting bug was left in-place. Better to under-promise and over-deliver, rather than the opposite. You may always compare the drive charts before and after a compression for the best results, as we have done on our home page.

They say every good tool is born out of a real need. I have been using NTFS compression myself since 2008, ever since my first SSDs, onto which I was unable to fit everything I needed. MagicRAR Drive Press was only built relatively recently in comparison, when I started researching ways to fit even more space onto disk - and was very pleasantly surprised by Windows's bug. I can assure all readers that NTFS compression, contrary to the FUD being spread here, is very safe and efficient. I would not use it on a mechanical drive, probably because the performance impact is made very noticeable due to the increased fragmentation. However on an SSD, MagicRAR Drive Press has become my own personal life-saver, helping me fit all my files and software onto disks that I would not have been able to fit into otherwise - even using Windows's built-in compression.

I realize this tool may not be needed by everybody, but for those who are looking to squeeze as much data as they can onto their drives, it is a life saver. I don't see a point in debating whether this Windows bug is really a bug or not. To me, it was clearly a bug because it was preventing me from compressing all of my drive, which was possible in previous Windows versions, and still remains possible. I consider the safety and authenticity of MagicRAR Drive Press to have been sufficiently proven even by the toughest of skeptics, and invite the rest of the world to enjoy the product.

As for the Magic...

There's plenty more Magic left in MagicRAR. You have only just begun scratching the surface. Why not take a look at the remainder product features? You may enjoy the instant benchmarking (Find Smallest Archive), shell namespace extension (Archive Folders), Outlook Integration (compressed attachment previews/automatic attachment compression) - to mention just a few.

wraith808

  • Supporting Member
  • Joined in 2006
  • **
  • default avatar
  • Posts: 11,186
    • View Profile
    • Donate to Member
Re: The MagicRAR Drive Press Challenge
« Reply #11 on: January 15, 2013, 10:15 AM »
And yes, there are limits for the reason you stated.  It's an int (16 or 32-bit depending on the version of comctrl32.dll [ref].
That reference mentions 64k limit - I wonder if comctrl uses signed or unsigned integers? It's been ages, but I seem to recall doing 32k clamping?

I think they're signed, but don't quote me on that; it's been ages for me too other than dabbling here and there.

Jibz

  • Developer
  • Joined in 2005
  • ***
  • Posts: 1,187
    • View Profile
    • Donate to Member
Re: The MagicRAR Drive Press Challenge
« Reply #12 on: January 15, 2013, 10:33 AM »
Could also be a rounding error -- you sometimes see programs where the last 0.5% show as 100%.

f0dder

  • Charter Honorary Member
  • Joined in 2005
  • ***
  • Posts: 9,153
  • [Well, THAT escalated quickly!]
    • View Profile
    • f0dder's place
    • Read more about this member.
    • Donate to Member
Re: The MagicRAR Drive Press Challenge
« Reply #13 on: January 15, 2013, 11:02 AM »
If the progress bars reached completion only a few minutes off, I am glad to hear that - it is very difficult to get them working properly, and a few minutes on hour/day long tasks is a very reasonable rounding error that I'm happy to live with.
How so? You're running an "analyze" pass over the entire drive, so you're able to get both a count of files as well as size in bytes - it's true that things can happen on the filesystem while you're compressing, but the VM was fairly idle... showing progress at 100% for 6 minutes before really done seems like an interesting bug.

I realize you personally may not test this, but if you actually test (...) on a production system (by running it after letting Windows do the initial work), you will still see two to three times the space savings compared to Windows itself. This is because Windows misses a majority of the files that are completely safe to compress (and were included in previous Windows versions). Yes, those files that Windows fails to compress do make that big of an impact.
On a "production system", those protected Windows files would be a much smaller percentage of the total amount of files. Your claim of "two to three times" is a dubious marketing strategy - since you use built-in NTFS compression (and thus offer no algorithmic improvements), it would be more honest to represent the absolute amount of gigabytes saved for typical systems. There's enough gains that this honest representation is still a fine number.

And actually, (...) somewhat under-reports the space it has freed by about 30% - this is because after a compression call to Windows has been made and it returns success, the compression (and space savings) still happen in the background for a few more minutes. It was not possible to definitively determine when Windows would be ultimately finished with compressing a file, so the under-reporting bug was left in-place. Better to under-promise and over-deliver, rather than the opposite. You may always compare the drive charts before and after a compression for the best results, as we have done on our home page.
Interesting. I haven't checked when the DeviceIoControl() call returns, but Windows' built-in COMPACT.EXE utility doesn't return until the file is compressed (so it's definitely possible to do without too much work) - and IMHO, watching the thread status in your product while compressing, it looked like your threads didn't progress to the next workitem before it was fully done with the current. Perhaps you have a bug in your code - like, not handling hardlinked files properly?

I don't see a point in debating whether this Windows bug is really a bug or not. To me, it was clearly a bug because it was preventing me from compressing all of my drive, which was possible in previous Windows versions, and still remains possible.
Got an URL to your Microsoft Connect bug report? :-)
- carpe noctem

simonking

  • Participant
  • Joined in 2013
  • *
  • Posts: 19
    • View Profile
    • Donate to Member
  • WarningUser is banned
Re: The MagicRAR Drive Press Challenge
« Reply #14 on: January 15, 2013, 01:01 PM »
I realize you are doing your best to find bugs in the software - as you had promised. Frankly, I think you would be much better rewarded if you actually undertook a similarly thorough review of MagicRAR itself! If you increase your attack surface to cover the entire product, you will most probably find that MagicRAR Drive Press, due to its low level nature, is the most well tested component of the entire suite. Hunting bugs elsewhere would be a lot more rewarding for you, I promise :)

I am not responding to your remainder points, because as with your earlier posts, what I wrote initially still applies. You may run some more tests (such as on a production system) and disprove your earlier assertions yet again (such as the alleged invalidity of the "three times better than Windows" claim). Please excuse me for not entertaining any further negativity/harassment from you or other posters. However I will hang around in case any fresh new questions come up that have not been brought up before.
« Last Edit: January 16, 2013, 04:51 AM by simonking »

simonking

  • Participant
  • Joined in 2013
  • *
  • Posts: 19
    • View Profile
    • Donate to Member
  • WarningUser is banned
Re: The MagicRAR Drive Press Challenge
« Reply #15 on: January 17, 2013, 03:15 AM »
Today is the last day of the MagicRAR Drive Press Challenge!

Thank you all for participating and please contact me for any claim submissions at simon at magicrar dot com.

Even if you have not won the challenge, please keep in mind that you can get a MagicRAR serial key for free for the first 30 days at http://www.magicrar.com/purchase.asp - if you are unsatisfied for any reason, simply cancel your order within the first 30 days and you will not be billed anything. Enjoy MagicRAR without the nag screens!

simonking

  • Participant
  • Joined in 2013
  • *
  • Posts: 19
    • View Profile
    • Donate to Member
  • WarningUser is banned
Re: The MagicRAR Drive Press Challenge
« Reply #16 on: January 18, 2013, 06:15 AM »
Thank you all very much for your participation in the MagicRAR Drive Press Challenge. The challenge has now been concluded.

More ways to get involved with MagicRAR:

- For Developers: Download the source code for the open source components of MagicRAR at https://github.com/magicrar. Contribute your changes. Our intelligent installer will automatically install your contributions once they have been approved, without having to manually rebuild the MagicRAR installer!

- For Consumers: Take a look at the eleven unique benefits of MagicRAR at http://www.magicrar.com/features.html. Download the latest version of MagicRAR at http://www.magicrar.com/download.html. Enjoy your product!