Are NTFS and Acronis compression incompatible ?

I have noticed that when Disc Cleanup is used to compress old files :-
It only saves half the space it promised to save, and
The next Acronis image is BIGGER.

Windows File Protection does not trust Windows compression, therefore some system files are duplicated into dllcache - but not enough to explain the Acronis bloat. I now find Acronis bloats even when nothing is added to dllcache.

I created 2 archive images at 11/11/2008 16:35:24 and 11/11/2008 20:59:52
Almost nothing changed, excepting
340 MBytes reduction on the space used on C:\
74 MBytes INCREASE in the size of the Acronis True Image Home version 11.0 image archive.
This indicates that a 20% reduction in space used on C:\ causes a 10% increase in the size of the Acronis image.

During those 4 hours, all I did was reboot into SAFE mode, and run Disc Cleanup to compress old files, free of aggravation from paranoid W.F.P. so no extra clutter was dumped in dllcache, and then I rebooted back to normal for creating the second image. During that time Windows knocked 4.2 MBytes of the size of iconcache, and let in another antivirus signature update, and prefetch probably got a few more items.

From what and where does Acronis get all the extra information ?

Till now I wanted to minimise redundant software and other junk, and I thought that having 60% free space was a good thing.
I now think that decompressing C:\ would increase the space used on C:\ but have no real affects (other than disc defrag could blow a fuse and give me perpetual BSODs !!!), BUT it would give a 10% reduction in the Acronis image size and allow me to hold 10% more images in the allocated space, i.e. I could retain an additional 2 or 3 earlier images.

When I read a file, Windows gives me exactly the same data regardless of whether it has been compressed.
Windows always has a "gotcha", so I just did a stupid test :-
Thunder.rtf, data size 4,769,171 bytes, size on disc 1,024,000 bytes.
I copied this to another folder and the copy is NOT compressed.
I then used PowerArchiver to create 7z and zip archives
Thunder.zip 289,241 bytes
Thunder.7z 42,088 bytes
These archive sizes were independent of whether they processed the NTFS compressed original, or the de-compressed copy.

If 7Z and ZIP archivers can totally ignore NTFS compression, why does Acronis have a problem ?
Is it because it does not receive the files in decompressed mode, but bypasses Windows and reads the raw sectors direct, and although the information is the same, Acronis is much less efficient at compressing what NTFS previously compressed ?

Alternatively, have I misunderstood the situation and overlooked something which is under my control, and which would allow Acronis to have the same efficiency regardless of whether the files it is dealing with have been subject to NTFS compression ?

Consequences of NTFS file compression on old files,having selected all contents of C:\* :-
7,822,413,687 - 7,818,290,373 = 4,123,314 (total size if uncompressed)
6,894,732,127 - 6,546,809,732 = 347,922,395 (actual space taken)
alternatively the ENTIRE C:\ including in-accessible profiles and all the super secret folders Windows refuses to show etc.
7,789,737,664 - 7,439,216,640 = 350,521,024 (space including entire C:\)

Regards
Alan

 

Alan:

Vista or XP?

 

Sorry I forgot to say.

Windows XP Home edition with SP3.
NB The unexpected bloat was also apparent when only SP2 was installed, but I have only made specific measurements since SP3.

Regards
Alan

 

Alan:

Then I don't have a theory to offer. If you would have said Vista then the daily shadow copy files, which keep track of changed sectors, would have been my first suspicion.

 

Alan and k0lo,

Thank you for using Acronis True Image

Alan, the issue you have experienced is very interesting. Please let us know if you want to continue to investigate the case.

Thank you.

__

Oleg Lee

 

Yes please Oleg, I would appreciate any information you can obtain.

At the moment the only remedy I can think of is to decompress all of Drive C, which would increase the disc space taken by 2 GBytes, and reduce the Acronis image by 400 MBytes.
I can afford to lose 2 Gbytes of free space out of the present 10 GBytes, and it would be nice if future Acronis images were 400 MBytes smaller so my External Drive archive "backup folder" could hold a few more retrospective disc images.

The problem is that when "Disc Cleanup" compressed old files and saved a mere 50 Mbytes, Windows File Protection demanded that I give it the Windows Installation discs (which were never supplied with pre-installed XP), so I am sure that a decompress expansion of 2 GBytes will be more than interesting, and if Windows survives that I suspect there will be more file fragments than the defragger can "shake a stick at".

I am blessed with the ability to see multiple solutions to a problem,
and am cursed with the ability to see and fear multiple unwanted consequences.

It is nice to know that if the system becomes un-bootable I can always use the Acronis restore CD to restore a working image.

But I will be very uncomfortable if I am ever forced to do that with nothing else to fall back on, so I will patiently wait for any advice you may be able to give

Regards
Alan.

 

Dear Alan,

Thank you for using Acronis True Image

Thank you for your response.

It will be more convenient to communicate via e-mail. This will allow to exchange with the required instructions and diagnostic files that can help us to give the issue a closer investigation and provide you with a probable solution.

Please send me your e-mail address as a private message, and I will let you know the case number.

Thank you.

__

Oleg Lee

 

Dear Oleg

Sorry for the long delay in responding.

Immediately after the December patch Tuesday update it was announced that a new threat had been "In the Wild" for a few months, and Microsoft hoped to fix it some time. I immediately accepted the advice to set I.E. for maximum security, and found that prevented Firefox from downloading executables. I also disconnected the Internet as much as possible and lived like a hermit.

As an experiment I created a new empty folder in C:\SysCopy and used Drag-n-Drop to copy Windows\system32 into that folder. This achieved about 80% until an inaccessible error aborted the copy.

The entire C:\SysCopy was decompressed.
I created two Acronis File backups, one before and one after compressing the entire C:\SysCopy.
The two backups were EXACTLY the same size as one another, which I assume indicates that a File Backup uses the normal Windows facilities that deliver upon request a fully decompressed copy of the desired file. Therefore I fear this gives no clue upon whether a Disc backup goes direct to the relevant sectors and finds the compressed contents indigestible !

All that experimental effort was a total waste, until I restored these backups to NTFS partitions on the external drive. I found the restored folders held exactly the same number of sub-folders and files as the original, and the same total size. BUT when I compressed the restored folders the "Used Space" was less than the anount taken on by the compressed C:\SysCopy.
The cluster size was 4 KBytes for both C: and the external drive F:\

The External drive was supplied pre-formatted for FAT32 for use by Windows 98 etc. The first thing I did was to use Windows disc management to convert it to NTFS.

Somehow Windows was more effective at compressing 978 MBytes on drive F:\ than the same 978 MBytes on drive C:\

It looks like magic.
I assume that the "size on disc" of C:\SysCopy represents the sectors occupied by the visible files, plus invisible things such as Alternate Data Streams which I know of, and Metadata which means nothing to me but the defragger is always complaining about. There are also file security permissions etc. Then Chkdsk always has complaints about
Cleaning up 6 unused index entries from index $SII of file 0x9.
Cleaning up 6 unused index entries from index $SDH of file 0x9.
Cleaning up 6 unused security descriptors.

I now assume that C:\SysCopy not only holds the files I can see, but also at least some related "invisible things" are also taking up "Size on Disc", and that Acronis discarded some of this "invisible junk" when creating its images.

MY CONCLUSIONS :-
I want to know everything;
My head hurts;
Windows does black magic against me and there is nothing I can do - I give up !

Meanwhile my Christmas present is an extra 100 GB of storage, which greatly reduces my urge to optimise a few hundred MB from the size of an image.

I am now focussing my efforts upon how to make most effective use of this extra 100 GB, so I will allow this thread to rest.

Thank you for your patience.

 

Hello alan_b,

Please accept our apologies for the delay with the response.

Actually, this situation is too complex to give you a workaround at current step of the investigation.

Please submit a request for technical support. Attach all the collected files and information to your request along with the step-by-step description of the actions taken before the problem appears and the link to this thread. To expedite the resolution we recommend you to use our Live Chat service after that. We will do our best to investigate the problem and provide you with a solution.

Thank you.
--
Alexander Nikolsky

 

Alexander,

Thank you, but I now wish to let this rest.

I am unfamiliar with appropriate procedures, but would appreciate it if this thread could be marked "Resolved" or whatever is deemed appropriate.

I wish to back out of this because I knew everything about file formats etc. when the first P.C.s came out with only a floppy disc.
I think that knowledge has met all my needs with the more recent FAT32.

I now realise that NTFS is a whole new ball game,
and learning what it does is like swimming in treacle - up a water-fall ! !

Having observed that C:\Syscopy can be copied to F:\,
and that both C:\Syscopy and F:\Syscopy can be subjected to NTFS compression,
and then confirmed with File and Folder comparison that they are both identical,
and then viewed File properties for both folders,
and seen (as expected) the "Size" is identical,
I was most surprised to find the F:\ duplicate occupied less "Size on Disc" than did the C:\ original.

Both C:\ and F:\ use default 4 kB cluster sizes, so I deduce that the C: original has more than the Files and Folders I knew of,
such as Alternate Data Streams and Meta-Data,
and this is affecting measurements.

Conclusion :-
I do not understand NTFS, and the more I observe it the more confused I become. I give up ! !

Regards
Alan