Yes, there's a lot of perplexing info about how to put
C:\Users or equivalents on a separate partition.
The following's not directly on topic, I know, but it might
be a help to the OP, as a kind or workaround, and some other responses have raised the
topic. In my opinion the OP's suggestion sounds super handy:
the following is not intended to detract from it in any way.
This is how I got Win 7 C:\Users on a separate partition.
1. Make a new partition on disk 0 (for C:\Users data), e.g.
after shrinking/compacting an existing partition.
So now disk 0 has the following partitions:
C:, G: (in addition to system and restore partitions)
2. Use the wonderful IFW to clone disk 0 to an identical disk, disk 1
Now on disk 1 partitions H: and J: correspond to partitions
C: and G: on disk 0. (H and J here are used for illustration as
I can't remember the actual letters.)
3. robocopy /mir /xj H:\Users J:\
(This takes a while.)
4. On H: , move Users to origUsers (a precaution, to save robocopying
everything back again if it all goes wrong). Then mkdir Users.
5. Go to Disk Management, right click on partition J: in disk 1.
Select Drive Letter and Paths. Then Add, to mount in the empty
H:\Users folder.
6. Shutdown. Replace disk 0 by disk 1 and reboot.
Now C:\Users is on a different partition, G:. Note there's no use of
explicit symbolic linking, mklink, etc, that are often recommended,
in the foregoing procedure.
Done this a few times & without any problem in the procedure.
So far, about a week only, everything works beautifully. Except
disk cloning, as mentioned in another post today. (The latter
maybe because I've missed something obvious--I'm new to Windows.)
Note: Coming from a long-term Unix background, I wanted to push
things to the next step, i.e. remove the drive letter from the
mounted drive G:. This too worked fine until I found that
one vital program would not start when the filesystem was configured
without a drive letter (the treasured mobaxterm Xserver, would you
believe). So have gone back to using drive letters ... Windows warns
about this issue: I just hoped the warning was applicable only to v. old programs.
I'm posting this here (a great forum) in case it's useful to anyone
else. OTOH, criticisms are super-welcome. It may all be wrong, for
some subtle reason beyond the ken of an amateur.
Regards,
Rick
Feature request: omit folders
Re: Feature request: omit folders
RickD wrote:
>
> The following's not directly on topic, I know, but it might
> be a help to the OP, as a kind or workaround, and some other responses have
> raised the topic. In my opinion the OP's suggestion sounds super handy:
> the following is not intended to detract from it in any way.
>
> This is how I got Win 7 C:\Users on a separate partition.
>
>...<snip>...
>
> Done this a few times & without any problem in the procedure.
>
> So far, about a week only, everything works beautifully. Except
> disk cloning, as mentioned in another post today. (The latter
> maybe because I've missed something obvious--I'm new to Windows.)
>
> ...<snip>...
>
> I'm posting this here (a great forum) in case it's useful to anyone
> else. OTOH, criticisms are super-welcome. It may all be wrong, for
> some subtle reason beyond the ken of an amateur.
>
I appreciate your post here. The trouble with such procedures is that they are not endorsed by Microsoft so may work or appear to work but could contain subtle flaws, such as the one you mention. I have also seen a number of other solutions on the internet but none seem to be popularly acknowledged as 100% correct, so I am reluctant to rely on them.
So I still feel that if TB could address this problem by adding my proposed capability to IFD/IFW it would be a significant additional feature and ought to widen the appeal and enhance sales. Is this capability in any competing program? (but I would really rather stick with the TB product line as otherwise I feel it fits my needs better)
>
> The following's not directly on topic, I know, but it might
> be a help to the OP, as a kind or workaround, and some other responses have
> raised the topic. In my opinion the OP's suggestion sounds super handy:
> the following is not intended to detract from it in any way.
>
> This is how I got Win 7 C:\Users on a separate partition.
>
>...<snip>...
>
> Done this a few times & without any problem in the procedure.
>
> So far, about a week only, everything works beautifully. Except
> disk cloning, as mentioned in another post today. (The latter
> maybe because I've missed something obvious--I'm new to Windows.)
>
> ...<snip>...
>
> I'm posting this here (a great forum) in case it's useful to anyone
> else. OTOH, criticisms are super-welcome. It may all be wrong, for
> some subtle reason beyond the ken of an amateur.
>
I appreciate your post here. The trouble with such procedures is that they are not endorsed by Microsoft so may work or appear to work but could contain subtle flaws, such as the one you mention. I have also seen a number of other solutions on the internet but none seem to be popularly acknowledged as 100% correct, so I am reluctant to rely on them.
So I still feel that if TB could address this problem by adding my proposed capability to IFD/IFW it would be a significant additional feature and ought to widen the appeal and enhance sales. Is this capability in any competing program? (but I would really rather stick with the TB product line as otherwise I feel it fits my needs better)
-
TeraByte Support
- Posts: 3624
- Joined: Thu May 05, 2011 10:37 pm
Re: Feature request: omit folders
If people really want "something", I can add the option to provide a file
that lists files/folders to "exclude", even though they wont' be excluded,
all their contents will be compressed to zero (restoring the file would be a
file of all zeros), but then remove them after the restore. This wouldn't
change any used/free space requirements or last used sector to fit smaller
areas/etc.. and the file/folders would still be there in tbiview/tbimount.
"TeraByte Support" wrote in message news:3248@public.image...
It's not file based product - omitting pagefile/hibernation file doesn't
remove the file, just compresses the file to zero, will still be there when
restored (just contents undefined or zero). You could always separate your
data on to a different partition and omit the partition.
"rustleg" wrote in message news:3246@public.image...
I'd like to ask if it's possible to consider adding a feature to IFD/IFW
which would allow you to specify particular folders to omit. There are 2
areas of a current typical Windows installation where the ability to omit
certain paths would be a huge benefit:
(1) The user's data. Windows is built with the assumption that everything is
stored on drive C including user data. Ideally you don't want this in an
image backup for 2 reasons. Firstly data backup needs to be made much more
often - in my case I do it at least once per day, sometimes many times. When
you restore you want the latest data, very unlikely to be in the TBI image
file. Data backup should be handled by other software and nowadays is likely
to go to the internet. The second reason not to back up data is it may be
many GB in size, creating very large image files which would mostly comprise
data you don't want to restore.
(2) Cloud backup services often use a dedicated folder to contain material
to back up to the internet. Sometimes of course these are not real locations
on the hard drive, but sometimes they are. Again this is user data which
doesn't really belong in a system image file, could be large in size and
would only be up to date for a very short time after the image is taken.
Cloud backup is easy and popular with many companies offering solutions and
many people must be using it or considering it.
It's not just Windows. In Ubuntu Linux - Ubuntu One is a service offering
free storage and it places the folder as a subdirectory of /home and this is
not user configurable. Personally I keep /home in the system image because
it contains configuration files. So this scenario is much like Windows in
having user data mixed with system files. I suspect there are a good number
of TB's users booting Linux systems as part of multiboot setups.
Currently I try to store user data on a different partition but Windows 7's
design makes this very difficult. It wasn't so bad with XP.
Of course there would be techical difficulties in implementation and TB may
say it would require too much of a rewrite of the software. However I am
encouraged by 2 considerations. Currently there are IFD/IFW options to omit
the Windows Page file and Hibernation file, and I see there is a utility
(TBIVIEW) to extract individual files from an image (although I haven't used
it). So I would expect some of the work to look into the file structure
within an image may already have been done. To simplify implementation
perhaps the program could look for a file with a particular name (example
$TBI_OMITPATHS.txt) in the root of the partition being imaged, being a
simple text file list of folders (including all subfolders) to omit, so no
change required to the screen layouts.
I'm sure a lot of people would find this a very significant upgrade. I tried
to look to see if such a feature has already been asked for here, but
couldn't find any. No doubt the regular lurkers here will know.
that lists files/folders to "exclude", even though they wont' be excluded,
all their contents will be compressed to zero (restoring the file would be a
file of all zeros), but then remove them after the restore. This wouldn't
change any used/free space requirements or last used sector to fit smaller
areas/etc.. and the file/folders would still be there in tbiview/tbimount.
"TeraByte Support" wrote in message news:3248@public.image...
It's not file based product - omitting pagefile/hibernation file doesn't
remove the file, just compresses the file to zero, will still be there when
restored (just contents undefined or zero). You could always separate your
data on to a different partition and omit the partition.
"rustleg" wrote in message news:3246@public.image...
I'd like to ask if it's possible to consider adding a feature to IFD/IFW
which would allow you to specify particular folders to omit. There are 2
areas of a current typical Windows installation where the ability to omit
certain paths would be a huge benefit:
(1) The user's data. Windows is built with the assumption that everything is
stored on drive C including user data. Ideally you don't want this in an
image backup for 2 reasons. Firstly data backup needs to be made much more
often - in my case I do it at least once per day, sometimes many times. When
you restore you want the latest data, very unlikely to be in the TBI image
file. Data backup should be handled by other software and nowadays is likely
to go to the internet. The second reason not to back up data is it may be
many GB in size, creating very large image files which would mostly comprise
data you don't want to restore.
(2) Cloud backup services often use a dedicated folder to contain material
to back up to the internet. Sometimes of course these are not real locations
on the hard drive, but sometimes they are. Again this is user data which
doesn't really belong in a system image file, could be large in size and
would only be up to date for a very short time after the image is taken.
Cloud backup is easy and popular with many companies offering solutions and
many people must be using it or considering it.
It's not just Windows. In Ubuntu Linux - Ubuntu One is a service offering
free storage and it places the folder as a subdirectory of /home and this is
not user configurable. Personally I keep /home in the system image because
it contains configuration files. So this scenario is much like Windows in
having user data mixed with system files. I suspect there are a good number
of TB's users booting Linux systems as part of multiboot setups.
Currently I try to store user data on a different partition but Windows 7's
design makes this very difficult. It wasn't so bad with XP.
Of course there would be techical difficulties in implementation and TB may
say it would require too much of a rewrite of the software. However I am
encouraged by 2 considerations. Currently there are IFD/IFW options to omit
the Windows Page file and Hibernation file, and I see there is a utility
(TBIVIEW) to extract individual files from an image (although I haven't used
it). So I would expect some of the work to look into the file structure
within an image may already have been done. To simplify implementation
perhaps the program could look for a file with a particular name (example
$TBI_OMITPATHS.txt) in the root of the partition being imaged, being a
simple text file list of folders (including all subfolders) to omit, so no
change required to the screen layouts.
I'm sure a lot of people would find this a very significant upgrade. I tried
to look to see if such a feature has already been asked for here, but
couldn't find any. No doubt the regular lurkers here will know.
Re: Feature request: omit folders
If this is implemented, you should strive to ensure that TBIView and
TBIMount show a consistent view of what the partition(s) would look
like if they were to be restored.
Also it appears that after a restore of a partition which contains
'excluded' items it will be necessary to run chkdsk /f?
Also, could there be a problem relating to the permissions of the
excluded items?
On Wed, 3 Oct 2012 09:33:24 PDT, "TeraByte Support"
wrote:
>If people really want "something", I can add the option to provide a file
>that lists files/folders to "exclude", even though they wont' be excluded,
>all their contents will be compressed to zero (restoring the file would be a
>file of all zeros), but then remove them after the restore. This wouldn't
>change any used/free space requirements or last used sector to fit smaller
>areas/etc.. and the file/folders would still be there in tbiview/tbimount.
>
>"TeraByte Support" wrote in message news:3248@public.image...
>
>It's not file based product - omitting pagefile/hibernation file doesn't
>remove the file, just compresses the file to zero, will still be there when
>restored (just contents undefined or zero). You could always separate your
>data on to a different partition and omit the partition.
>
>
>
>"rustleg" wrote in message news:3246@public.image...
>
>I'd like to ask if it's possible to consider adding a feature to IFD/IFW
>which would allow you to specify particular folders to omit. There are 2
>areas of a current typical Windows installation where the ability to omit
>certain paths would be a huge benefit:
>(1) The user's data. Windows is built with the assumption that everything is
>stored on drive C including user data. Ideally you don't want this in an
>image backup for 2 reasons. Firstly data backup needs to be made much more
>often - in my case I do it at least once per day, sometimes many times. When
>you restore you want the latest data, very unlikely to be in the TBI image
>file. Data backup should be handled by other software and nowadays is likely
>to go to the internet. The second reason not to back up data is it may be
>many GB in size, creating very large image files which would mostly comprise
>data you don't want to restore.
>(2) Cloud backup services often use a dedicated folder to contain material
>to back up to the internet. Sometimes of course these are not real locations
>on the hard drive, but sometimes they are. Again this is user data which
>doesn't really belong in a system image file, could be large in size and
>would only be up to date for a very short time after the image is taken.
>Cloud backup is easy and popular with many companies offering solutions and
>many people must be using it or considering it.
>
>It's not just Windows. In Ubuntu Linux - Ubuntu One is a service offering
>free storage and it places the folder as a subdirectory of /home and this is
>not user configurable. Personally I keep /home in the system image because
>it contains configuration files. So this scenario is much like Windows in
>having user data mixed with system files. I suspect there are a good number
>of TB's users booting Linux systems as part of multiboot setups.
>
>Currently I try to store user data on a different partition but Windows 7's
>design makes this very difficult. It wasn't so bad with XP.
>
>Of course there would be techical difficulties in implementation and TB may
>say it would require too much of a rewrite of the software. However I am
>encouraged by 2 considerations. Currently there are IFD/IFW options to omit
>the Windows Page file and Hibernation file, and I see there is a utility
>(TBIVIEW) to extract individual files from an image (although I haven't used
>it). So I would expect some of the work to look into the file structure
>within an image may already have been done. To simplify implementation
>perhaps the program could look for a file with a particular name (example
>$TBI_OMITPATHS.txt) in the root of the partition being imaged, being a
>simple text file list of folders (including all subfolders) to omit, so no
>change required to the screen layouts.
>
>I'm sure a lot of people would find this a very significant upgrade. I tried
>to look to see if such a feature has already been asked for here, but
>couldn't find any. No doubt the regular lurkers here will know.
>
TBIMount show a consistent view of what the partition(s) would look
like if they were to be restored.
Also it appears that after a restore of a partition which contains
'excluded' items it will be necessary to run chkdsk /f?
Also, could there be a problem relating to the permissions of the
excluded items?
On Wed, 3 Oct 2012 09:33:24 PDT, "TeraByte Support"
wrote:
>If people really want "something", I can add the option to provide a file
>that lists files/folders to "exclude", even though they wont' be excluded,
>all their contents will be compressed to zero (restoring the file would be a
>file of all zeros), but then remove them after the restore. This wouldn't
>change any used/free space requirements or last used sector to fit smaller
>areas/etc.. and the file/folders would still be there in tbiview/tbimount.
>
>"TeraByte Support" wrote in message news:3248@public.image...
>
>It's not file based product - omitting pagefile/hibernation file doesn't
>remove the file, just compresses the file to zero, will still be there when
>restored (just contents undefined or zero). You could always separate your
>data on to a different partition and omit the partition.
>
>
>
>"rustleg" wrote in message news:3246@public.image...
>
>I'd like to ask if it's possible to consider adding a feature to IFD/IFW
>which would allow you to specify particular folders to omit. There are 2
>areas of a current typical Windows installation where the ability to omit
>certain paths would be a huge benefit:
>(1) The user's data. Windows is built with the assumption that everything is
>stored on drive C including user data. Ideally you don't want this in an
>image backup for 2 reasons. Firstly data backup needs to be made much more
>often - in my case I do it at least once per day, sometimes many times. When
>you restore you want the latest data, very unlikely to be in the TBI image
>file. Data backup should be handled by other software and nowadays is likely
>to go to the internet. The second reason not to back up data is it may be
>many GB in size, creating very large image files which would mostly comprise
>data you don't want to restore.
>(2) Cloud backup services often use a dedicated folder to contain material
>to back up to the internet. Sometimes of course these are not real locations
>on the hard drive, but sometimes they are. Again this is user data which
>doesn't really belong in a system image file, could be large in size and
>would only be up to date for a very short time after the image is taken.
>Cloud backup is easy and popular with many companies offering solutions and
>many people must be using it or considering it.
>
>It's not just Windows. In Ubuntu Linux - Ubuntu One is a service offering
>free storage and it places the folder as a subdirectory of /home and this is
>not user configurable. Personally I keep /home in the system image because
>it contains configuration files. So this scenario is much like Windows in
>having user data mixed with system files. I suspect there are a good number
>of TB's users booting Linux systems as part of multiboot setups.
>
>Currently I try to store user data on a different partition but Windows 7's
>design makes this very difficult. It wasn't so bad with XP.
>
>Of course there would be techical difficulties in implementation and TB may
>say it would require too much of a rewrite of the software. However I am
>encouraged by 2 considerations. Currently there are IFD/IFW options to omit
>the Windows Page file and Hibernation file, and I see there is a utility
>(TBIVIEW) to extract individual files from an image (although I haven't used
>it). So I would expect some of the work to look into the file structure
>within an image may already have been done. To simplify implementation
>perhaps the program could look for a file with a particular name (example
>$TBI_OMITPATHS.txt) in the root of the partition being imaged, being a
>simple text file list of folders (including all subfolders) to omit, so no
>change required to the screen layouts.
>
>I'm sure a lot of people would find this a very significant upgrade. I tried
>to look to see if such a feature has already been asked for here, but
>couldn't find any. No doubt the regular lurkers here will know.
>
-
TeraByte Support
- Posts: 3624
- Joined: Thu May 05, 2011 10:37 pm
Re: Feature request: omit folders
"Tom Cole" wrote in message news:3341@public.image...
If this is implemented, you should strive to ensure that TBIView and
TBIMount show a consistent view of what the partition(s) would look
like if they were to be restored.
>> That wouldn’t happen. they would be there, especially with tbimount.
>> just all zeros in the file.
Also it appears that after a restore of a partition which contains
'excluded' items it will be necessary to run chkdsk /f?
>> no.
Also, could there be a problem relating to the permissions of the
excluded items?
>> no.
On Wed, 3 Oct 2012 09:33:24 PDT, "TeraByte Support"
wrote:
>If people really want "something", I can add the option to provide a file
>that lists files/folders to "exclude", even though they wont' be excluded,
>all their contents will be compressed to zero (restoring the file would be
>a
>file of all zeros), but then remove them after the restore. This wouldn't
>change any used/free space requirements or last used sector to fit smaller
>areas/etc.. and the file/folders would still be there in tbiview/tbimount.
>
>"TeraByte Support" wrote in message news:3248@public.image...
>
>It's not file based product - omitting pagefile/hibernation file doesn't
>remove the file, just compresses the file to zero, will still be there when
>restored (just contents undefined or zero). You could always separate
>your
>data on to a different partition and omit the partition.
>
>
>
>"rustleg" wrote in message news:3246@public.image...
>
>I'd like to ask if it's possible to consider adding a feature to IFD/IFW
>which would allow you to specify particular folders to omit. There are 2
>areas of a current typical Windows installation where the ability to omit
>certain paths would be a huge benefit:
>(1) The user's data. Windows is built with the assumption that everything
>is
>stored on drive C including user data. Ideally you don't want this in an
>image backup for 2 reasons. Firstly data backup needs to be made much more
>often - in my case I do it at least once per day, sometimes many times.
>When
>you restore you want the latest data, very unlikely to be in the TBI image
>file. Data backup should be handled by other software and nowadays is
>likely
>to go to the internet. The second reason not to back up data is it may be
>many GB in size, creating very large image files which would mostly
>comprise
>data you don't want to restore.
>(2) Cloud backup services often use a dedicated folder to contain material
>to back up to the internet. Sometimes of course these are not real
>locations
>on the hard drive, but sometimes they are. Again this is user data which
>doesn't really belong in a system image file, could be large in size and
>would only be up to date for a very short time after the image is taken.
>Cloud backup is easy and popular with many companies offering solutions and
>many people must be using it or considering it.
>
>It's not just Windows. In Ubuntu Linux - Ubuntu One is a service offering
>free storage and it places the folder as a subdirectory of /home and this
>is
>not user configurable. Personally I keep /home in the system image because
>it contains configuration files. So this scenario is much like Windows in
>having user data mixed with system files. I suspect there are a good number
>of TB's users booting Linux systems as part of multiboot setups.
>
>Currently I try to store user data on a different partition but Windows 7's
>design makes this very difficult. It wasn't so bad with XP.
>
>Of course there would be techical difficulties in implementation and TB may
>say it would require too much of a rewrite of the software. However I am
>encouraged by 2 considerations. Currently there are IFD/IFW options to omit
>the Windows Page file and Hibernation file, and I see there is a utility
>(TBIVIEW) to extract individual files from an image (although I haven't
>used
>it). So I would expect some of the work to look into the file structure
>within an image may already have been done. To simplify implementation
>perhaps the program could look for a file with a particular name (example
>$TBI_OMITPATHS.txt) in the root of the partition being imaged, being a
>simple text file list of folders (including all subfolders) to omit, so no
>change required to the screen layouts.
>
>I'm sure a lot of people would find this a very significant upgrade. I
>tried
>to look to see if such a feature has already been asked for here, but
>couldn't find any. No doubt the regular lurkers here will know.
>
Re: Feature request: omit folders
TeraByte Support wrote:
> If people really want "something", I can add the option to provide a file
> that lists files/folders to "exclude", even though they wont' be excluded,
>
> all their contents will be compressed to zero (restoring the file would be
> a
> file of all zeros), but then remove them after the restore. This wouldn't
>
> change any used/free space requirements or last used sector to fit smaller
>
> areas/etc.. and the file/folders would still be there in
> tbiview/tbimount.
>
> ...<snip> ...
(Sorry I haven't revisited this forum for a few days)
Wow, this is great! Putting "something" in quotes above seems to suggest this is only a half solution, but I think this is exactly what I would want. The restored zeroed files should be deleted, as you suggest, since they would be historic data files no longer relevant. The omitted folders would remain but contain nothing (except subfolders).
It would then be up to the user to use a data backup from their data backup software to restore the latest files to their original location. I have tested restoring a set of files from a main folder backup (which contains files in a tree of subfolders) using a simple copy and paste in Linux file manager (Nautilus) to a matching heirarchy of empty folders. After it asks one question to confirm that the contents should be merged with existing folders in the destination, it proceeds without problem. I think the same applies in Windows. Merging into empty folders is not a problem. Folders which remain empty could be manually deleted later or just ignored. Folders that weren't merged because they were not in the original system would just be recreated by the data restore. Of course if some software had been updated in the meantime it might cause errors when trying to run the old version. You would have to remove it and reinstall the latest version of the application (but you wouldn't have to reinstall Windows and all other software!)
I can't think of a more logical way to do this. It seems to fit perfectly.
I don't understand your points about tbiview/tbimount, but only because I haven't used these utilities. But I can't imagine anyone would consider viewing the "omitted" files since they are omitted because they were not required in the image. If they want to rescue a copy of the omitted files they would look in their data file backups.
It would mean I could work with one large C partition in Windows, but have an image backup which was not huge but contained a complete system easily restored. Data restored from a data backup (via other software or just using the standard file manager) would be the most recent. Old data would not be restored to confuse me. Perfect!
I'd be interested in what Dr Teeth would say about this, since he expressed a wish for this facility.
> If people really want "something", I can add the option to provide a file
> that lists files/folders to "exclude", even though they wont' be excluded,
>
> all their contents will be compressed to zero (restoring the file would be
> a
> file of all zeros), but then remove them after the restore. This wouldn't
>
> change any used/free space requirements or last used sector to fit smaller
>
> areas/etc.. and the file/folders would still be there in
> tbiview/tbimount.
>
> ...<snip> ...
(Sorry I haven't revisited this forum for a few days)
Wow, this is great! Putting "something" in quotes above seems to suggest this is only a half solution, but I think this is exactly what I would want. The restored zeroed files should be deleted, as you suggest, since they would be historic data files no longer relevant. The omitted folders would remain but contain nothing (except subfolders).
It would then be up to the user to use a data backup from their data backup software to restore the latest files to their original location. I have tested restoring a set of files from a main folder backup (which contains files in a tree of subfolders) using a simple copy and paste in Linux file manager (Nautilus) to a matching heirarchy of empty folders. After it asks one question to confirm that the contents should be merged with existing folders in the destination, it proceeds without problem. I think the same applies in Windows. Merging into empty folders is not a problem. Folders which remain empty could be manually deleted later or just ignored. Folders that weren't merged because they were not in the original system would just be recreated by the data restore. Of course if some software had been updated in the meantime it might cause errors when trying to run the old version. You would have to remove it and reinstall the latest version of the application (but you wouldn't have to reinstall Windows and all other software!)
I can't think of a more logical way to do this. It seems to fit perfectly.
I don't understand your points about tbiview/tbimount, but only because I haven't used these utilities. But I can't imagine anyone would consider viewing the "omitted" files since they are omitted because they were not required in the image. If they want to rescue a copy of the omitted files they would look in their data file backups.
It would mean I could work with one large C partition in Windows, but have an image backup which was not huge but contained a complete system easily restored. Data restored from a data backup (via other software or just using the standard file manager) would be the most recent. Old data would not be restored to confuse me. Perfect!
I'd be interested in what Dr Teeth would say about this, since he expressed a wish for this facility.
Re: Feature request: omit folders
On Mon, 8 Oct 2012 14:22:04 PDT, just as I was about to take a herb,
rustleg disturbed my reverie and wrote:
>I'd be interested in what Dr Teeth would say about this, since he expressed a wish for this facility.
Just spent HOURS putzing about troubleshooting an issue where my OS
disk would not boot ANY OS (ALL would boot half-way and then stall)
and would pass Seagate tests. After all that, turned out to be a SATA
socket that was acting up. I am hating the little buggers - but I
digress. It's well past my planned bed time because of this.
I would love this feature if it meant that less space would be needed
for a backup, and the backup and restore itself would be quicker, I'm
all for it. My games folder is 168GB - all I need to restore it is a
list of the games installed or a single screenshot. Save data is
stored elsewhere in Win 7. I would LOVE to exclude that folder from
IfW backups.
--
Cheers
DrT
______________________________
We may not be able to prevent the stormy times in
our lives; but we can always choose whether or not
to dance in the puddles (Jewish proverb).
rustleg disturbed my reverie and wrote:
>I'd be interested in what Dr Teeth would say about this, since he expressed a wish for this facility.
Just spent HOURS putzing about troubleshooting an issue where my OS
disk would not boot ANY OS (ALL would boot half-way and then stall)
and would pass Seagate tests. After all that, turned out to be a SATA
socket that was acting up. I am hating the little buggers - but I
digress. It's well past my planned bed time because of this.
I would love this feature if it meant that less space would be needed
for a backup, and the backup and restore itself would be quicker, I'm
all for it. My games folder is 168GB - all I need to restore it is a
list of the games installed or a single screenshot. Save data is
stored elsewhere in Win 7. I would LOVE to exclude that folder from
IfW backups.
--
Cheers
DrT
______________________________
We may not be able to prevent the stormy times in
our lives; but we can always choose whether or not
to dance in the puddles (Jewish proverb).
Re: Feature request: omit folders
DrT,
If you had installed your games into another partition you wouldn't have this problem. The Games partition would only need to be imaged rarely and your OS image would be small. Sorry, but you should have anticipated this problem.
If you had installed your games into another partition you wouldn't have this problem. The Games partition would only need to be imaged rarely and your OS image would be small. Sorry, but you should have anticipated this problem.
Re: Feature request: omit folders
Brian, you're assuming that Dr T had the choice to install things in a different partition. This facility seems to be less and less available these days. Microsoft's philosophy is to avoid asking the user anything about partitions, drive letters, etc. They want to remove technical questions from their users experience to reduce the learning curve for the average user. This is entirely understandable and laudable.
So it means everything must go on C and they don't support installation elsewhere. The same applies to software apps - they often don't give the option to install on some other partition. With multi-terabyte discs, everything can go on one big partition - why bother to have other partitions?
Of course our answer to that question is that it makes image files huge. And any included user data quickly becomes out of date.
So imagaging becomes less useful as a means of system backup. Is this why MS have their "system restore points"? But as we know, these are a poor solution to rolling back the OS. They often won't revive a system which has had a problem. Also who would want to rely on them if the system was infected? The only sure way to disinfect a system is to wipe the drive and reinstall from scratch or restore from an earlier image.
You could say that MS do acknowledge the usefulness of sytem images since in Windows 7 they have their own built-in system image facility. I have tried it and it is very poor, not a patch on TB's programs. If you do install something on another partition they also automatically include the whole of the other partition in the system image! It's not configurable (again illustrating their philosophy of removing technical questions).
So the basic problem is that system recovery is best handled with occasional system images (the whole raison d'etre of TB's software) and data recovery by frequent data backups e.g. Google Drive has a background process which immediately backs up changes. The two don't mix well. But TB's proposal to include zeroed data files, as specified by the user, fits the bill perfectly, as I have explained above. Personally I think, if implemented, this should extend the life of IFD/IFW as viable software.
You can go on googling for some geek's recipe for relocating user data for software which doesn't support it, but I'd prefer to install systems in line with the way they were designed.
So it means everything must go on C and they don't support installation elsewhere. The same applies to software apps - they often don't give the option to install on some other partition. With multi-terabyte discs, everything can go on one big partition - why bother to have other partitions?
Of course our answer to that question is that it makes image files huge. And any included user data quickly becomes out of date.
So imagaging becomes less useful as a means of system backup. Is this why MS have their "system restore points"? But as we know, these are a poor solution to rolling back the OS. They often won't revive a system which has had a problem. Also who would want to rely on them if the system was infected? The only sure way to disinfect a system is to wipe the drive and reinstall from scratch or restore from an earlier image.
You could say that MS do acknowledge the usefulness of sytem images since in Windows 7 they have their own built-in system image facility. I have tried it and it is very poor, not a patch on TB's programs. If you do install something on another partition they also automatically include the whole of the other partition in the system image! It's not configurable (again illustrating their philosophy of removing technical questions).
So the basic problem is that system recovery is best handled with occasional system images (the whole raison d'etre of TB's software) and data recovery by frequent data backups e.g. Google Drive has a background process which immediately backs up changes. The two don't mix well. But TB's proposal to include zeroed data files, as specified by the user, fits the bill perfectly, as I have explained above. Personally I think, if implemented, this should extend the life of IFD/IFW as viable software.
You can go on googling for some geek's recipe for relocating user data for software which doesn't support it, but I'd prefer to install systems in line with the way they were designed.
Re: Feature request: omit folders
Russell,
That hasn't been my experience at all. The only app I have that won't install to another partition is a Garmin mapping program. So I use a junction point to move the Garmin folder from the OS partition to the big programs partition. As you mention, we prefer to have our OS images as small as possible. Mine take 90 seconds to create.
I've tried an imaging app that gives you the choice to exclude folders. As TeraByte Support indicated, the zeroed folders have to be deleted after a restore and the backed up folders copied into the OS partition. I found this messy and it isn't something I'd like to work with.
That hasn't been my experience at all. The only app I have that won't install to another partition is a Garmin mapping program. So I use a junction point to move the Garmin folder from the OS partition to the big programs partition. As you mention, we prefer to have our OS images as small as possible. Mine take 90 seconds to create.
I've tried an imaging app that gives you the choice to exclude folders. As TeraByte Support indicated, the zeroed folders have to be deleted after a restore and the backed up folders copied into the OS partition. I found this messy and it isn't something I'd like to work with.