Compressed snapshots - incompatible?

Hello Gang!

I'm not asking for support, I just want to share some experience (relax, Peter).

So, I did install the Leapfrog 1.10 build 169 and I converted my snapshots to compressed snapshots.

I'm tester of beta software for TrendMicro Internet Security software and in that role I have to provide logfiles to TrendMicro.
Well, today I found out that in a compressed snapshot the logfiles are not created at all, also not when FD-ISR is uninstalled.
I checked this with running the same test in an not-compressed snapshot, where the logfiles are created.

Isn't that interesting?

 

Tiny correction: FDISR totally uninstalled, NTFS compression still enabled : No Log

The logfile is written as c:\UnpackTime.log.
Maybe this is not related to FD-ISR, I can only find out by zeroing my harddisk and then do the TrendMicro run in a freshly installed Windows without any FD-ISR, with and without NTFS compression.

Anyway, the anticipated NTFS compression might have unforseen side effects, would you not agree?

 

Not for the whole disk, but for all folders in the compressed snapshot.
(If all your snapshots are compressed, that would basically mean that the whole disk is compressed.)

Here you see the effect:
Compressed or encrypted files/folders show in color blue.

http://www.geocities.com/wilbertnl/images/fd-isr_compressed.png

 

Maybe I wasn't clear in the first entry, but the required logfiles are created in a not-compressed file system.
So, I was able to finish what I have to do, I just wanted to share my experience.

 

Is an ACTIVE snapshot also compressed?
I thought compression was only for non-active snapshots and archived snapshots.

 

Yes sir.
From the Leapfrog website: (http://www.leapfrogsoftware.com/support_info/updates/)

 

As far as I understand FDISR will become a mixture of compressed and not compressed snapshots, which means that source and target snapshot can be either compressed or not compressed.

For instance :
1. refreshing where source = compressed snapshot and target = not compressed snapshot
2. refreshing where source = compressed snapshot and target = compressed snapshot
3. refreshing where source = not compressed snapshot and target = not compressed snapshot
4. refreshing where source = not compressed snapshot and target = compressed snapshot
Let's hope it works.

 

This is the current situation in version 1.05 build 166, would you not agree?
You are able to test all the other situations by creating one or two folders with NTFS compression enabled in your data partition and test all situations by copying files to your liking.

 

So, let's say:

• your Primary Snapshot is uncompressed
• you copy your Primary to a Secondary Snapshot, which is compressed
• then, the Primary you're operating in go south, bites the dust
• then, you boot into your Secondary
• then, you copy your Secondary into your Primary
• then, you boot back into the refreshed Primary

Is any part of the new Primary compressed (that wasn't before) ?

If not, then it appears the above procedure would be the preferred route for recovering the Primary if you want no compression in the Primary or any of the potential conflict or problems with software like Trend Micro PC-cillin Internet Security (which I hold two licenses for).

 

Yes, I agree.
I've been playing with two test folders, uncompressed and compressed, but all files keep their size, compressed (blue) or uncompressed (black).
There should be a difference in size or am I missing something ?

 

Yes, Explorer will display the uncompressed size. If you want to see the difference between compressed and uncompressed, check the "properties" of the file and compare "size" to "size on disk".

 

Right. The properties show the difference. Thanks.

 

What is the size of the folders that contain these files?

 

I have not tested this scenario, but it might show you something:
(For rainy sunday afternoons)

Assuming you use version 1.05 build 166.

1. Create a empty snapshot.
2. Uninstall FD-ISR, keep the snapshots. The C:\$ISR folder structure will be visible and accessible.
3. Look in C:\$ISR for the 1,2,3,4,5-folder that is EMPTY.
4. Enable NTFS compression for that particular folder.
5. Install FD_ISR.
6. Copy a regular snapshot or archive into the empty snapshot that you created in step 1 and compressed in step 4.
7. Calculate the snapshot size of the NTFS compressed snapshot and compare that with the source.
8. Boot into the compressed snapshot and play!

 

It's OK. Crofftk showed me how to read the normal size and compressed size.

 

Situation
Snapshot-01 = 3.09 gb ($ISR/0)
Shapshot-02 = 3.57 gb ($ISR/1)

1. Created an empty snapshot
2. Snapshot-03 = 0.00 gb ($ISR/2)
3. Uninstalled FDISR (programs only)
4. Compressed $ISR/2
5. Re-installed FDISR
6. Copy/Update from Snapshot-02 (3.57gb) to Snapshot-03 = empty and compressed (blue)
7. Calculate Snapshot-03 = 3.57 gb
So it has the same size as snapshot-02

Rebooted in snapshot-03 and it worked.

MS Windows Explorer shows :
A blue C:\RECYCLER (Folder)
A blue C:\$ISR\2 (Folder = snapshot-03)
A blue C:\$ISR\$ISR (file)
The rest seems to be black.

 

Hm,
\Documents and Settings, \Program Files and \Windows should be blue too.

When I have a compressed folder in my data partition and I create a new folder in it (with Windows Explorer), the new folder is compressed too.
But it seems that your snapshot-3 is not compressed. The calculated size is equal to the source.

So, this is what I learned from your test, ErikAlbert (thank you):
I open the CMD window and change to the compressed folder. And in that compressed folder I create a new folder (md folder).
That new folder, created by other means than Windows Explorer, is not compressed.
So, the ISRcontrol.exe of build 166 is not aware of the compression attribute, and the 169 version is.

Surprising, because I thought that the NTFS driver would handle that.

 

Yes, it was a good idea, but it was a flop LOL.
Meanwhile I recovered my system partition with ATI, just to be safe.