Hi Barry,
Scenario:
1. Restored a 2007 backup to disk, 35 GB total.
2. Next Preview tallies 9018 files, 3.685,42 MB, which seems to be correct, all those are on other drives/folders.
3. The 'Select files to remove from backup' window shows 21,889,63 MB worth of changes in the restored folders, but I did not make any changes to them, nor did Preview spot any.
When I sampled some of the hits, they all seemed to have their filedate set to almost one hour (0:59:58, to be precise) earlier.
4. When I cancel un-select, I get the Start/Preview/Cancel dialog, showing the proper numbers again. I didn't press Start, so I don't know what will happen when I proceed.
I recently installed AISBackup 2.6.1.321 and use XP Pro SP2 build 2600.
Barry, it seems there's something wrong with the date routines in the selection window, but I can't figure out why not all files are wrong (only about 60% shows up 'changed').
Then a perhaps unrelated question. I see that some of the folders in the 'Select for backup' window have pink letters. What does that mean? I see no difference in Explorer.
All the best,
Aquarjen.
Some restored files immediately show up as changed
Restored files shown as changed
Let me see if I have got this scenario correct:
You have an on-going backup started at least some time in 2007, the last backup was run quite recently in Summer 2008 (daylight saving).
You restored to a winter copy of 2007 (not daylight saving).
You then ran another backup and all files that were 59:58 different time stamp were selected for backup again.
This has something to do with daylight saving and AISBackup does usually work in this respect. What I cannot figure is the 59:58 time difference (which is just on the boundary of the resolution of file date/time of FAT systems (AISBackup does take this into account).
Was it a restore to a formatted drive or an ‘over the top of the existing operating system’ restore?
Some tests will be run to see if this problem can be duplicated (and then repaired) here.
Meanwhile, if you can afford the disk space I would run the backup and 60% of your files will be re-backed up.
If ‘Show file attributes’ is set ‘pink folders’ are read only.
Barry
You have an on-going backup started at least some time in 2007, the last backup was run quite recently in Summer 2008 (daylight saving).
You restored to a winter copy of 2007 (not daylight saving).
You then ran another backup and all files that were 59:58 different time stamp were selected for backup again.
This has something to do with daylight saving and AISBackup does usually work in this respect. What I cannot figure is the 59:58 time difference (which is just on the boundary of the resolution of file date/time of FAT systems (AISBackup does take this into account).
Was it a restore to a formatted drive or an ‘over the top of the existing operating system’ restore?
Some tests will be run to see if this problem can be duplicated (and then repaired) here.
Meanwhile, if you can afford the disk space I would run the backup and 60% of your files will be re-backed up.
If ‘Show file attributes’ is set ‘pink folders’ are read only.
Barry
Backing up files just restored
If you have not run the backup yet I would like you to try a test version of AISBackup. Please let me know and I will upload a slightly modified version.
Barry
Barry
Re: Backing up files just restored
Oops, just trashed the backup! :o(Barry wrote:If you have not run the backup yet I would like you to try a test version of AISBackup. Please let me know and I will upload a slightly modified version.
Barry
I've done some extensive testing and have come to these conclusions.
1. I have recently joined drive D: and E:, what moved my music to D:. I used Paragon Partition Manager, which resetted the time 1 hour, but I don't see what that should do to the restored files as AISBackup rewrites all timestamps.
2. I got AISBackup to move the contents of E: on backup to D:. A preview showed no problems. Although, I must say that I saw some weird behavior of AISBackup; not sure what went on.
3. WMP doesn't seem to want you to move your music, so (un)happily experimenting away with that, I trashed the files (they all got renewed dates). This is what made me do a restore.
4. After restoring, Preview gave the strange results I mentioned in my initial post.
5. After lots of experiments I found that the most recent backup database is missing about 60% of my music tracks. Sounds familiar, huh? Not sure what went wrong, not sure why timestamps are different. Testing against another backup revealed no changes. The problem (at least for now) seems to be that I restored from an older backup (from before the transition) and it got Previewed against what AISBackup thought there should be on disk right now.
6. There are still strange things going on but I still cannot put my finger on what, exactly. I've seen different counts in several screens. If I see them again I'll try to document what I see.
I'm currently in the process of restoring my backup (I use two USB drives, one is still untouched with drive E: on it) so I can see what happens when I tell AISBackup to move the contents of E: to D: again.
The restore will take at least another four hours. I'll keep you posted.
Thanks Barry,
Aquarjen
Edit: PS: Not to cloud the issue any farther, but the initial backup was created in a different timezone (one hour, did you guess? ;o)
Time Zone
The different time zone should not have made a difference of the drive is formatted as NTFS as dates are stored a UTC (or GMT to us Brits 
), but it will if FAT32 which are stored as your local time. Some older versions of AISBackup did not work too well with dates; however if the initial backup was taken with a version of AISBackup made in the last 4 years then the dates should be okay.
The reason why the recently restored files were selected for backup is because they have different dates to the last (Summer Time) backup session, this may be something to do with the partition updates - Paragon Partition Manager may have caused the problem but I do not want to pass on any blame.
Restoring NTFS backup to NTFS should always be okay, but as soon as FAT32 drives come into the equation strange things may start happening. Also if the NTFS file security settings are not backed up then the date resolution may drift + or - 2 seconds as the normal zip file time resolution is the same as FAT32, but when NTFS file security and settings are backed up AISBackup stores additional date and time information. You do not need to restore NTFS security even if it is backed up.
My tests restoring a backup taken in November 2007, and then backing up again based on a more recent backup worked okay, i.e. only expected differences were backed up.
Barry
), but it will if FAT32 which are stored as your local time. Some older versions of AISBackup did not work too well with dates; however if the initial backup was taken with a version of AISBackup made in the last 4 years then the dates should be okay.The reason why the recently restored files were selected for backup is because they have different dates to the last (Summer Time) backup session, this may be something to do with the partition updates - Paragon Partition Manager may have caused the problem but I do not want to pass on any blame.
Restoring NTFS backup to NTFS should always be okay, but as soon as FAT32 drives come into the equation strange things may start happening. Also if the NTFS file security settings are not backed up then the date resolution may drift + or - 2 seconds as the normal zip file time resolution is the same as FAT32, but when NTFS file security and settings are backed up AISBackup stores additional date and time information. You do not need to restore NTFS security even if it is backed up.
My tests restoring a backup taken in November 2007, and then backing up again based on a more recent backup worked okay, i.e. only expected differences were backed up.
Barry
Re: Time Zone
I use NTFS everywhere, except USB pendrives, most of which slow down too much with the journalling NTFS does.
I cloned my trashed backup from the other drive I use as an alternating two-drive backup set. AISBackup reads the job from the drive that's connected at that time and adds all it's missing to that particular backup.
This is what I saw happening:
1. After cloning, I disconnected the original backup drive and opened the job from the All Jobs tab, and went to Backup Maintenance and assigned all entries of drive E: to drive D:.
At this time AISBackup is supposed to ask if I want the source for those files changed to D: too, but it didn't.
Apparently in this situation AISBackup used the local database on harddisk instead of the one on the drive and now I own the first 2.5" drive that can easily hold partitions of 4.462.662.790.736,15 MB and even negative sizes.
2. After repairing the damage I now explicitly opened the job from the USB drive, shuffled the data around again so I could delete E: from the backup in it's entirety. AISBackup severely slowed the system down for a while, trashed Excel (could be the other way round, of course) and presto, correct numbers! Well, for now, at least.
3. I cleaned up the database by removing old unneeded stuff and ran a Preview and a following backup, and all seems well.
Except that from time to time the numbers don't seem to be correct. In the 'Select files to remove from backup' window, I've actually seen that in one situation it has the amount of bytes ready to backup noted to the right of the main folders, and in another instance, it's the total number of bytes *already backed up". This is what happened in my initial post and it confused me; I expected an amount close to none, as, to my knowledge, no files were modified, but instead I got a number over 20 GB. (I'm desperately hoping this 'feature' is not by design, Barry...)
Renaming Jobs.
Now that I've successfully created a job without the removed drive E:, the job name is wrong, since the name contains all drive letters included. How do I rename a job (including the folder on the backup media), without corrupting anything?
Read-Only attributes.
I've got some Read-Only folders, probably copied from an R/O source like a CD or something. In the back of my mind I knew Windows XP doesn't really support R/O folders, and that it uses the bit for other purposses. You plainly cannot reset the R/O attribute with Explorer, and that's why they won't be removed from folders that got them (they'll show up when you add the Attribute column). Although it looks like its processing the umptheen hundred folders on my drive, it doesn't really.
The only way that seems to work is using a dosbox:
cd \path\mainfolder
attrib -R /S /D
This should reset all R/O attributes of all files in all subfolders, including the folders.
I cloned my trashed backup from the other drive I use as an alternating two-drive backup set. AISBackup reads the job from the drive that's connected at that time and adds all it's missing to that particular backup.
This is what I saw happening:
1. After cloning, I disconnected the original backup drive and opened the job from the All Jobs tab, and went to Backup Maintenance and assigned all entries of drive E: to drive D:.
At this time AISBackup is supposed to ask if I want the source for those files changed to D: too, but it didn't.
Apparently in this situation AISBackup used the local database on harddisk instead of the one on the drive and now I own the first 2.5" drive that can easily hold partitions of 4.462.662.790.736,15 MB and even negative sizes.
2. After repairing the damage I now explicitly opened the job from the USB drive, shuffled the data around again so I could delete E: from the backup in it's entirety. AISBackup severely slowed the system down for a while, trashed Excel (could be the other way round, of course) and presto, correct numbers! Well, for now, at least.
3. I cleaned up the database by removing old unneeded stuff and ran a Preview and a following backup, and all seems well.
Except that from time to time the numbers don't seem to be correct. In the 'Select files to remove from backup' window, I've actually seen that in one situation it has the amount of bytes ready to backup noted to the right of the main folders, and in another instance, it's the total number of bytes *already backed up". This is what happened in my initial post and it confused me; I expected an amount close to none, as, to my knowledge, no files were modified, but instead I got a number over 20 GB. (I'm desperately hoping this 'feature' is not by design, Barry...)
Renaming Jobs.
Now that I've successfully created a job without the removed drive E:, the job name is wrong, since the name contains all drive letters included. How do I rename a job (including the folder on the backup media), without corrupting anything?
Read-Only attributes.
I've got some Read-Only folders, probably copied from an R/O source like a CD or something. In the back of my mind I knew Windows XP doesn't really support R/O folders, and that it uses the bit for other purposses. You plainly cannot reset the R/O attribute with Explorer, and that's why they won't be removed from folders that got them (they'll show up when you add the Attribute column). Although it looks like its processing the umptheen hundred folders on my drive, it doesn't really.
The only way that seems to work is using a dosbox:
cd \path\mainfolder
attrib -R /S /D
This should reset all R/O attributes of all files in all subfolders, including the folders.