Michel Amyot wrote:I am testing QRecall right now and I like it a lot. But... because there is a but, is there a way to «delete» files from a layer?

Yes, but you'll have to wait 24 hours.

The new feature will appear in version 1.1.0(33) which is currently baking. It will permit you to delete all instances of an item from all layers.

The layer delete and merge commands delete items horizontally (deleting all old items across an entire layer). The new item delete command deletes items vertically (deletes a single item from every layer).

Is it hidden somewhere or is it prohibited?

It's not prohibited, it just took some time to get it functional.

Michel Amyot wrote:Is there a way with QRecall to perform such function?

QRecall is really designed to capture incremental changes of your file to an archive, not create more copies of your files.

Or could it be implemented in the future?

Currently planned for version 1.3 will be the ability to schedule an action to run when an item changes (this feature will require Leopard). You will then be able to create an action to capture your working project file or folder automatically every time it's modified.

If you need to recover an earlier version, select the document, right/control+click, and choose the Recall command (you can do that now).

An interim solution you can try now is to schedule an action to capture just your project folder at some reasonable interval. This is what I do with my QRecall project files. I have an archive just for the QRecall project, and an action recaptures the project folder every 20 minutes. Since QRecall only captures changes, most of the time the capture does nothing. I can recover any changed file going back a week with a 20 minute resolution.

You may think: «Who needs that kind of backup strategy?»

I don't have to ask.

The previous fix for the SMB volumes wasn't Intel specific and the problem being reported by the G4 is completely different than the problem encountered by your Intel system. I suspect that the old version of QRecall that had problems with the SMB volume on the Intel would have had the same problems on the G4. If it didn't have that same problem, then that would be interesting.

I also wouldn't be surprised at all if there were subtle platform-specific differences between the Samba drivers on the G4 vs. those your Intel system.

I was hoping you had an update.

I can find nothing in the code to explain what's happening. So for now I'm going with the assumption that the problem is coincident with using this particular storage device.

The first diagnostic is to try it with a different device. You were going to perform the same capture on the same machine using an external drive. Have you had a chance to do that, and were the results different?

Thanks!

Christian,

I'm glad to hear that things are working satisfactorily again. I'm mildly curious as to why the other capture was taking so long; maybe the log file contains a clue.

The issue of QRecall continuing to use an archive that's been dragged into the Trash isn't new. It's caught more than one user by surprise. I'm not entirely sure what the solution is, but I've made a note to try and deal with that situation in a future version.

Christian Roth wrote:While the initial capture took its time (about 9 hours), the second capture now takes over 15 hours and I am about half way through it.

15 hours seems like a long time, but it's not unheard of. It depends mostly on how much new data is being added to the archive and the speed of the volume containing the archive.

Any capture that adds a lot of new data (i.e. tens of GBs) can spend a considerable amount of time organizing and reorganizing the archive database. This is usually encountered during the "closing archive" phase of the capture, but it can happen in the middle of the capture too. The result is that QRecall appears to be spinning its wheels (sometimes for hours) while it updates and sorts its index of quanta.

Other confounding factor: The speed and latency of the archive volume (particularly networked volumes and USB drives). How much RAM the system has (less than 1GB will cause QRecall to run much less efficiently). Running other applications at the same time (causes virtual memory swapping and reduces the amount of RAM available for buffering data).

I checked in Intstruments and find a lot of very small (in size) accesses using PBWriteForkSync and PBReadForkSync. Should this be happening?

Probably. My guess is that QRecall is capturing a lot of small (&lt32K) files to a relatively large (&gt100GB) archive and/or your system doesn't have a lot of RAM. (A semi-informed guess based on your I/O trace.)

I guess that the constant head movement slows down the capture significantly, but maybe it's ok.

Excessive head movement is generally bad, and really slows things down, but in a few cases is unavoidable. The real killer is when QRecall decides that it needs to resize its lookup tables. This can thrash the archive volume for hours while it copies really tiny bits of data from one index to another. Indexes are resized exponentially, so this will only occur a few times during the life of the archive; but it is especially likely to occur during the first few large captures.

As you see, there are many 12-byte-long reads and 4, 5 or 6 byte writes. Is this supposed to be handled by the OS' caches or would these accesses (since synced??) actually result in hard drive access?

When using Instruments or iosnoop, you're tracing the requests that come from the application, not the physical I/O to/from the drive. All of these small reads and writes are (typically) buffered by a RAM cache that tries to minimize the actual I/O to the volume. Of course, there are limits and the more RAM you have the more efficient this buffering will be.

Just wondering if that behaviour is expected and normal.

Unless QRecall gets stuck or stops with an error, I'm inclined to assume that it's doing the best it can with what its got. Let the capture finish -- send a diagnostics report afterwards if you like -- and then see what the performance of subsequent captures is like.

gery houiller wrote:I do synchronize 2 Xserve servers with 1.5 TB of remote data by an ADSL line.

That's a lot of data to try to capture via a DSL connection. Right now, QRecall only writes to mountable volumes. So you would have to mount the volume with the archive using some form of remote file services, such as AppleShare IP.

Is that your software can handle as much data and how
long does it take to verify the state files a knowing synchronize
it has 30 gigabytes of data per month amended.

It can handle that much data, but there are too many variables to say how long it will take. My only suggestion would be to get a trial identity key and run a test.

Is it necessary to check the status of each file every day or do you use the tool of verification of time machine in the mac os 10.5.4 to avoid to scan all files.

QRecall uses the same file system change event technique that Time Machines uses under OS X 10.5. However, this can't be trusted indefinitely. There are a number of subtle situations where OS X 10.5's change information can be inaccurate. So approximately once a week, QRecall will ignore the change information and perform a deep scan of every item on the volume. This period can be adjusted.

David Cretney wrote:Using the drop down arrows to navigate the library is cumbersome, I'd sure like to be able to navigate by double click and only use the task bar button for restore- or make it configurable.

There are two alternate browsing modes that I've had on my to-do list for eons, but I've never gotten much feedback about the browser so I've left it be for now. That, and any change to the browser would be a huge amount of work.

I've considered a single-window browser. Opening a folder would replace the contents of the window with the contents of the opened folder. This is, more or less, how single-window browsing in the Finder works. But then there are navigation issues (i.e. how do you get back).

Another option, and the one I'm most fond of, is to implement a column browser mode.

Anyone have any input or reaction to these suggestions?

ubrgeek,

I just looked at the log file you sent and it's a bit of a mystery. The capture is fails to write to the archive with OS error -51. This is an "invalid reference number" error.

When an application opens a file, it gets a "reference number" which it then uses to read and write to that file. When the file is closed, that reference number becomes invalid.

I can't think of any good reason why this might be happening. Some file/operating systems have limits about how many files can be open at once. I'm wondering if the SMB drivers on the PowerMac is losing track of what files it has open? Or maybe the volume is getting disconnected and reconnected (this happens all the time on my WiFi), and after reconnecting it has forgotten what files it had open? (I'm mostly thinking out loud here.) I'll post this question on one of the technical forums and see if anyone has any good ideas.

ubrgeek wrote:Can I send along the log file and see if you have any ideas?

Always. Just choose Help > Send Report... and I'll take a look at it.

David Cretney wrote:Did switching from trial to paid lock me out of captures that were created while I was using a trial key?

No, they're still there. They just belong to a different user.

An identity key is just that: It identifies the owner of the captured items. When you changed keys, you changed identities. Items captured before September 1 belong to the trial key owner. Items captured after belong to your permanent key.

Open up the Owners and Volumes drawer (View > Show Owners & Volumes). There you will see the set of owners and volumes captured in the archive. Select a volume to switch between them. The layers that contain items belonging to that owner & volume are active. The layers that do not contain any items belonging to the selected owner and volume are grayed out.

Welcome, David.

David Cretney wrote:I really hope the development continues. It appears the 1.0.1 has been around for awhile now.

If 5 months is "awhile now," then I guess 1.0.1 is getting long in the tooth. sigh Internet time moves so quickly.

Despite the developers intentionality in creating a simpler user experience, I guess it has partly been the change of vocabulary, and partly just the change in doing things

I've struggle mightily with the terminology of QRecall, and that's one of its consistent criticisms. The problem is that QRecall does do things differently. So the choice is to reuse teminology that's inappropriate, or introduce new terminology that's unfamiliar. I've decided that I can't win for losing.

but I haven't always found that QR does what I would have hoped or expected.

That's exactly what these forums are here for. If something's confusing, inconsistent, or unexpected, please share those experiences. It will either improve QRecall or your understanding of QRecall.

Steven M. Alper wrote:When I restarted the icons for my external Firewire hard drive's two partitions had been changed to generic icons.

That's suspicious.

However this morning I was notified that QRecall was unable to find its archives on that disk.

QRecall remembers the location of both archives and items to be captured using aliases. These are the same alias records created by the Finder when you make an Alias file.

I suspect that AppleJack has changed something that OS X was using to identify known volumes. This would also explain why your icons changed (since OS X now thinks these are new, never before seen, volumes). You might check to see if you have any other aliases to items on your external volume. They might be suffering from the same problem.

You can probably rectify this by editing your actions. Open the action, reselect the same archive (creating a new alias to the archive) and save the updated action.

/private/var/db/volinfo.database

Yikes! /var/db/volinfo.database is not a transient file. I would definately alert the AppleJack authors about this one.

One of the important bits of information stored here is which volumes use POSIX Ownership and Privileges and which ones don't. Erasing this file could cause volumes that previously enforced file ownership and privileges to suddenly stop using them and visa versa.

I don't see anything QRecall related in there, but what do I know.

I don't either. I think AppleJack just gave OS X a case of amnesia and it no longer remembers volumes that it's seen in the past.

Chris Caouette wrote:I am always nervous about a backup to an unknown file format.

I sympathize with your concern.

QRecall archives use a proprietary file format. There is no commercial filesystem available that provides the kind of storage organization that QRecall needs. So it simply isn't possible to provide the kind of features that QRecall does with an existing filesystem. (In an interesting footnote, Apple couldn't implement Time Machine with the standard HFS+ filesystem either. Apple had to alter the HFS+ volume format to get Time Machine to work.)

Is there a way to recover if the backup file gets an error?

Absolutely. QRecall includes a comprehensive Repair command that will systematically scan the raw data blocks of an archive, clear out any damaged data blocks, and reassemble all valid data back into a functional archive.

QRecall archives, unlike standard filesystems, were specifically designed with data recovery in mind. Filesystems are designed to be fast. QRecall archives are designed to be robust and compact. The archive contains several levels of redundant information so that the loss of archive data limits the loss of information to the fewest number of captured items as possible.

In fact, I would go so far as to encourage anyone who's interested to put this to the test. Create a QRecall archive, then use a Hex editor or some other method to poke holes in the archive data, run a Repair, and see what happens.

Archives also contain internal consistency checks that standard filesystems don't have. Every block of data in an archive includes a checksum, which is verified every time that data is read. There have been more then one QRecall user who discovered a drive that was occasionally returning invalid data because QRecall, and QRecall alone, complained when reading from that volume.

What happens if Dawn to Dusk stops production on Qrecall?

I will be very sad. The QRecall application, however, will continue to run. If the future of the application puts your data at risk, you can always recall it to a traditional filesystem and re-archive it using other means.

I had this happen already with a nice backup program that was going great then suddenly the company shut down.

I feel your pain.

I am not having a ton of luck with Time Machine (I have 3 computers and the drive is a 1TB on a AEBS). Qrecall looks like the answer but I am just making sure I have my rear covered.

You're welcome to try QRecall free of charge to see if it meets your needs. If you have questions, problems, concerns, or suggestions, the forums are always open.