Jump to content

Roxio Community

Recovering disk space used by BackOnTrack saved states


  • Please log in to reply
1 reply to this topic

#1 SoCalKen99

SoCalKen99

    Newbie

  • Members
  • Pip
  • 1 posts

Posted 23 October 2009 - 09:42 AM

I'm using BackOnTrack 3 Suite.  It is currently using 40+ GB of space on my boot partition for saved states.  I've removed all saved states the app will allow & the reported size for saved states has not gotten appreciably smaller.

I tried using Disk Cleanup & checked the option to remove BackOnTrack saved states, but that did not reclaim the disk space either.

The OS is Vista Ultimate 32-bit.

Responses from tech support have been totally off-topic and unhelpful.

Anyone have any information on this?


#2 isrjs

isrjs

    Newbie

  • Members
  • Pip
  • 1 posts

Posted 02 August 2011 - 04:32 PM

I realize this is an old post, but since I only came up against this issue today, while working on a friend's Mini, I will add the solution I came up with to this post.

The instructions we followed to clean up the disk space didn't work.
Nothing was accomplished, nothing was deleted, even though I attempted multiple variations.
The instructions I am referring to, are to use the disk cleanup option within Roxio BackOnTrack.
The disk cleanup process identified about 12 GB of saved system states, but would not remove them when executed.

I tried deleting the sub-directories within the ROLLBACK directory manually, but kept getting an error due to an inaccessible folder (SrtETMP).
Continuing on manually was not feasible since there were over 500 subfolders within the saved state folder.

My search for information on the Internet was not helpful.
However, I was finally able to remove the Roxio BackOnTrack Saved States folders.

I came by the solution as sort of an accident.
I thought that if I moved all the sub-folders into one single folder, then any folders that had the inaccessible folder SrtETMP would be left behind, and all the ones that were accessible would be copied to the new folder.
Then all the accessible sub-folders could be deleted in one fell swoop, without the error message popping up.
This was not a complete solution, but at least some space may have been recovered with this method.

However, when I executed the copy command, ALL the sub-folders were copied into the single folder I created.
I was then able to delete ALL the saved state folders at one time, without encountering the error message regarding an inaccessible folder.

I don't recall the entire path of the folder where the saved system states are located.
But it is similar to this one(C:\System Rollback\etc.).
Keep drilling down within the folders until you get to the CURRENT folder, and its sub-folders.
My friend had over 500 saved state folders within the final sub-folder, consuming 8 gigs of disk space, leaving him with 0 space available.
I had to move the virtual RAM file (pagefil.sys) to the 2nd partition (D:\), to get some working space.

So, that was the solution for me.
1. Create a new folder in the same folder where all the other saved states are located
2. Select all the folders you want to remove, and move them to your newly created folder.
3. Select all the folders within your newly corrected folder, and do a shift-delete.

That's all it took for me.
You can delete the newly created folder once you're done with it.

As always, Your Mileage May Vary
I hope this works for you.

p.s. I must give credit where credit is due.
The remote control software TeamViewer saved me a 100-mile round-trip drive to resolve this issue for my friend.
Check it out if this type software would be helpful to you (no I don't work for them).
Never have, but I'm open to offers, as I'm currently unemployed. ;-D :P
By the way, it's free for noncommercial use. I use it all the time to help my friends.

Forgive me: The system was a Compaq Mini running Windows XP 32-bit.
I don't recall if it was Home or Professional version.

Edited by isrjs, 02 August 2011 - 04:35 PM.





0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users