Disk space used and TI's compression

To see how effective is TI's compression, it is necessary to know how many bytes are actually on the source drives to be backed up.

Over the years, I've needlessly wasted time starting My Computer and copying the info into an Excel spreadsheet to determine disk use.

I finally got around to writing a quickie program to get the info.

See http://www.standards.com/index.html?GetDiskSpaceUsed

P.S. (Added on 26 December 2005)
Also, See http://www.standards.com/index.html?GetFileTypeDistribution

 

Hello Howard,

Thank you for choosing Acronis Disk Backup Software.

Sharing your experience is very much appreciated.

If you have any further experience to share, please feel free to post it on this forum.

Thank you.
--
Alexey Popov

 

Thanks for the link Howard. Perhaps it's worth pointing out that TI doesn't save the actual Windows Paging File or Hibernation File (if used) into its image - just a few bytes of "placeholder" information in each case. I think this needs be born in mind if comparing the effectiveness of TI's compression algorithms.

Regards

 

Yes, and I've got another program that helps analyze this.

http://www.standards.com/index.html?GetFileTypeDistribution

I originally wrote the above to get a handle of the distribution of file types used, as one well known backup program has, in my opinion, very unsatisfactory compression due to its choice of which file types to compress.

I also have an updated version of GetFileTypeDistribution which could have other uses, but I don't know when I'll be able to post it.

 

I posted the update a bit ago.

See http://www.standards.com/index.html?GetFileTypeDistribution

 

Hello Howard,

Many thanks. Two handy little utilities, which I can confirm run fine under Windows XP SP2. Slight problem with column spacing in the File Type Distribution (see screenshot) but that's no big deal.

Regards

 

The program should work on any windows OS that has VB 6, or its runtimes, and supports the used API calls. So win 2000 and Win XP should work. Probably would also work in Win 95, Win 98 and Win ME, just an issue of whether those OS support the API calls used.

The output is exactly as I said it would be. I explicitly stated that the output was TAB delimited so the output could be inserted into Word/Excel. I saw no reason to pretty up the output.

I thought about adding an option to create Excel spreadsheets, but then I have to go thru additional work when compiling/testing the program. Not worth it in this case.

 

According to the Windows aPI Reference at the MSFT web site, one of the API calls requires at least Win 95 OSR2, the others require only at least Win 95.

So, the program should work on Win 95 OSR2 and later.
I might be able to change to work in vanilla Win 95, but I ain't gonna do so.

 

Understood. Thanks.

 

I just tested in vanilla Win 95, there's also the issue of file naming.
The files names have to be able to include, e.g., two dots and/or spaces and or whatever, so program may not work in OS not supporting long file names and spaces and whatever.

 

OK, I Just posted a new version that allows for both an Excel workbook and a text file to be output.

 

Got it thanks. A handy little tweak.

Regards

 

I foolishly started the tweak after midnight and got sucked in.
I better grab something to eat and get to bed.

 

Put out a new version a few minutes ago.
Just slightly faster for Excel spreadsheet, too tired to do this last night.

 

Hi Howard.. I tried GetFileTypeDistribution on my C drive. No problem there. I then tried it on my S drive where I have three ATI backups stored. The program just hung there. Waited for about 10 minutes, then stopped it via Task Manager. Using WinXP He. Here is the ouput from DiskSpaceUsed:

Start: 6:55:25 on 29 December 2005
Drive Total Bytes Free Bytes Available Bytes Used Bytes Used(%)
A
C 30737838080 17559228416 17559228416 13178609664 42.87%
D
E
F 65568768 65568768 65568768 0 0.00%
S 33805864960 5374304256 5374304256 28431560704 84.10%
Total 64609271808 22999101440 22999101440 41610170368 64.40%
End: 6:55:26 on 29 December 2005

 

Try the following:

1. Select ALL drives.
2. Select the text only output.
3. Hit the Get Lists button
4. Hit the ByeBye button to exit.

Did that work?

If so, try the same, but ask for Excel only output.
Did that work?

This type of program cannot really hang, unless there's a broken API or Excel on your system.

As I recall. Menorcaman stated that he had used the pre-Excel version on XP SP2.

If the code works to the text only output, then I expect that there could be a problem with Excel on your system, or with a 3rd party add-in interacting with Excel.

 

Hi Howard... OK, I got things sorted out. I must have checked the Excell output instead of the Txt output. Txt output works fine.

 

Thanx.

That would indicate that your system either has a broken Excel, or more likely, a 3rd party add-in that is interfering with Visual Basic's ability to programmatically start Excel.

What version of Office are you using?

I've seen such problems due to various versions of Acrobat and Norton Auntie Virus. Others have reported similar problems due to other apps. The problem most often occurs with Word, less so with Excel.

One suggestion, if you have Norton Auntie Virus, disable the NAV Office plug-in, but make sure that NAV's AutoProtect is enabled. Not sure if this could be the problem, as I never have the Office plug-in enabled.

 

Hello Howard,

I can confirm that your latest version works fine under Windows XP (Home) SP2 in combination with Excel 2000 (v9.0.6926 SP3).

Regards

 

Thanx.
As I built the EXE with Excel 97, and developed with Excel 2003, and you used Excel 2000, I'll try Excel 2002.

The problem should not be OS related as I'm using standard API calls, indeed, I expect that some are the very same API calls that TI uses in the file based operations.

The program does explicitly test whether Excel has started.
If not, an error message is issued, and, if text output has not also been requested, the program exits.

So, if the error message is not being seen, then Excel is starting, but something is preventing further opeations on Excel.

 

It's not a broken Excel, it's a non-existent Excel. I don't have MS Office on my computer. Sorry, I should have indicated that in my last response.

 

OK.

I do not have systems without Excel, so I guess all my systems are EXCELent,
I tested by faking that Excel was not present and the code ran.

I'll be posting a new EXE later that has added checks for Excel.
Maybe I missed one in the EXE you were using.

 

That's OK, I think the earlier code ASSuMEd that Excel would be on the system, so it needed one more bit to exit gracefully.

I just put up a new version that should work on a system that has no Excel.

 

Forgot to mention, latest version of GetFileTypeDistribution program is 2.1.0.0.

 

Have you, or anybody else, tried the most recent download on a system that does not have Excel?

See http://www.standards.com/index.html?GetFileTypeDistribution