Is there a way to mark a file so that a merge would not delete it, even if deleted in layers being merged? If not could some kind of marking, say a file name additive like [ ] around the nam, be put into your "to do" list?

I am just worried that I might delete accidentally a copy of some old file that had not been used for awhile that I really did not want to.

If I get the layer and merge idea correct, a file could be lost by a deletion that makes it to the last layer before merge.

I realize that I could have a copy of old "not being used" files where I was not likely to mess with them, but that is not as easy as keeping all my related files together. If I did have such a copy, it would be nice if recall had a marker to mark files you do not want captured that are in a directory that you do want captured.

By the way, great program concept and I am doing a capture right now to a FAT32 networked attached (NSLU) USB drive that seems to be working fine.

Al Pawlowski

Al Pawlowski wrote:Is there a way to mark a file so that a merge would not delete it, even if deleted in layers being merged? If not could some kind of marking, say a file name additive like [ ] around the nam, be put into your "to do" list?

Is your primary concern that you want to make sure you keep the last copy of each file in the archive?

Trying to merge two layers (where a file exists in the earlier layer but doesn't exist in the latest layer) but keeping the deleted file doesn't fit the model used by QRecall. A layer is a snapshot of the what files do, and do not, exist at a single point in time. The only way to keep the older copy of the file would be to maintain a second layer -- which is exactly what you already had before the merge. So the short answer to this problem is don't merge.

I've considered this and similar problems in the past and have been toying with a number of possible solutions. But I haven't come up with any yet that are both simple and keep the layer information consistent.

Here's my suggestion: If you have a group of files that you want to keep the last version each day, use two archives.

Create one archive for your active documents that you capture on a daily or hourly basis and a second for everything else. For the first, have a rolling merge keep daily layers for that archive going back as far as you want (30 day, 6 months, ...). Unless you're working on large multimedia files, keeping a year or more of daily backups of your documents shouldn't take up too much space. Because of QRecall's efficiency, a layer with no changes takes up virtually no storage.

Use a second archive to store everything else on the volume. That can be captured daily or weekly, and you probably only need to keep a few daily layers before merging older layers into weekly or monthly layers.

This will let you restore your OS or applications folder with a fairly recent version should something happen to it, while being able to recall that last version of the day of any document during the past year.

I realize that I could have a copy of old "not being used" files where I was not likely to mess with them, but that is not as easy as keeping all my related files together. If I did have such a copy, it would be nice if recall had a marker to mark files you do not want captured that are in a directory that you do want captured.

When creating a capture action, you can add whatever files or folders you want to the filter section. Those items will be ignored (treated as if they did not exist) during the capture. This lets you exclude whatever you want from regularly scheduled captures.

By the way, great program concept and I am doing a capture right now to a FAT32 networked attached (NSLU) USB drive that seems to be working fine.

QRecall should be able to use an archive on virtually any file system that correctly supports file sizes larger 2GB.