I have been unable to isolate any problems on our side...I thought I had found something the other day but upon further investigation, it ended up not being anything.

I am able to follow your steps and fully restore the files from an existing backup location to a target folder just fine even when that target folder no longer exists..

Upon further examination of the screen shots you supplied below, I can see the folders but not any of the files within those folders; I'm talking about the actual revision files that will contain the revision timestamp as part of their filename.  Revisions can be stored in either the DocumentDirectory or the Library; Depending on what option you have configured...It is important to note that storing the revision in the document's directory is the default.  In your desired configuration, it is imperative that the revision files be stored within the library and not in the document's directory or else the revision history will be deleted along with your document's directory when you 'torch' your harddrive.

I think some of the confusion here stems from the fact that you can see the folders within the library; The Library will always contain a mirror the directory structure because the settings and options are always stored in the library even when the revisions are stored within the documents directory.

Scan down into the library's folders and look for files that look like this:
   Test.txt{Rev 2010;09;07 01;04;55 AM}.txt
These are the revision files...

I'm still convinced that your revisions were being stored in the document's directory; When revisions are stored in the document's directory they will be stored within a '.Backups' folder inside each folder of a watch and would have been deleted when you erased your drive.

If I am mistaken in my assertions then we should try scheduling an online session together where I can see more closely what behavior you are seeing...This online web sessions have proven to be very valuable in isolating issues which have proven to be difficult to replicate internally.

Okay, I've found an issue but I have not yet fully nailed down yet so I'm still not positive as to where it is stemming from...

Apparently, there are certain circumstances when creating a new library and new watch off that library where the 'RevisionStorageLocation' option says the revisions will be stored in the library but in fact, they are getting stored inside the '.Backups' folders within the document directory.  If this option is toggled to 'DocumentDirectory' then back to 'Library' things seem to be properly initialized and will begin to work as expected.

In the case you have outlined, I believe the revisions are in fact being created in the DocumentDirectory unexpectedly so when the drive is torched, you also happen to loose the revisions for the files that were stored within the document's directories as well leaving just the DocumentInfo files behind in the Library which contain some information about the document but not the revisions themselves.

To verify this, notice that there will be a '.Backups' folder created within the document's directory when you create a new revision in the middle of your test.  If you toggled the 'RevisionStorageLocation' option you will be able to see these files get moved over to the Library where they should have been stored in the first place...At which time, things will then begin to work properly from there on...This has something to do with the initialization of the inherited options for a new library getting only half initialized...

I'll have to do more digging into this one later as its solution has been alluding me thus far this evening...

I'll be checking into this shortly; I'll continue this thread from your other post as it has an excellent example for testing...

Yeah, doing that for now.. have a lot of various folders using symbolic links, though. Mainly just didn't work as expected
Thanks for the reply!

Sorry about the delay...

I'll try this out and see what the result are; Thanks for your excellent, well-thought out example!

Yes, symbolic links would be interesting...In the mean time, you just need to make sure your watches are covering the actual path where the symbolic links are pointing.

It looks like there isn't support for symbolic links in file hamster..

I use symbolic links for syncing with DropBox and I also have file hamster backup my dropbox folder on each of my computers connected to my dropbox account.  But recently found out that filehamster wasn't backing up my symbolic links.

I realize that just straight up implementing could potentially lead to infinite loop cases (symbolic link of a parent folder).. but I doubt it would be very hard to do checks to make sure it doesn't back up folders that have already been backed up.

Pretty soon I think you'll start seeing more people use symbolic links if anything just to save space for Solid State Drives (we use them at work).  It would be awesome if had support for this

Hi,

Can someone with a testing computer try this...

Install FH on a test computer that has 2 logical drives on the same physical drive.
Make FH watch one of your directories like the My Documents folder for example.
Make sure the revisions are saved to the 2nd logical drive (like D: or something)
Make several different files an modify each one several times to get some revisions out there.
Make some subdirectories under the My Documents as well and save some files in there too.

Torch your C: drive
reinstall FH
See if you can get those files back to your C: drive in their same locations.

I can't seem to figure out how to do that.

At this point - please see the 2 attached pictures.

It appears FH overwrites something and all the files in the D: repository ARE STILL THERE but you can't restore them because in the FH watch tree there's nothing below a particular branch to install.

Like if you've created a few directories under My Documents - you'll see them in the D: repository but you will not see them in the watch tree under the My Documents folder.

What is up with this?

No - I have the revisions stored in a directory on a different logical drive on the same physical drive.

What this lets me do is save stuff to my C drive and have it FH'ed to my D drive FH directory so when I torch my C drive I can just reinstall all my software (fh being one of them) and tell FH to restore all that.

Please take a look at the image in one of my replies above and you'll see there are only a few directories that FH sees in the backup FH dir on the D drive.  When you go to the FH dir on the D drive it shows there are A LOT MORE than what FH reports.

Why is that?

Herb

You should be able to mount and unmount libraries at anytime within FileHamster...We tried to make the libraries as mobile as possible so they can be moved about by the user as easily as possible.  However, once the library has been relocated, it then needs to be remounted in the FileHamster interface.  The revisions stored within the library should transfer over just fine because we use the actual revision files and their encoded timestamps for tracking the revisions on disk.  As long as there is a revision file located on the disk, it should be detected by FileHamster.

Just out of curiosity, do you store your revisions in the document's directory or in the library's directory?  If you have '.Backups' folders scatter about your watch directory then the revisions are being stored within the document's directory...This may play a role in locating the already existing revisions and getting them migrate properly when a library is moved...