1. Forgot to say: verification turned up no error.

2. Forgot to ask: the archive is set to keep deleted items for 0 days. Why are deleted items still there after being compacted?

UPDATE: the following is kept for the record, but it's a false alarm (see the 3rd post below).


It's been a while since I last checked in here because QR2 betas have been doing well on my system. Or so I thought, until this morning when I checked out my system archive (the one backing up my system partition).

I can't believe what I saw: the contents of the /Applications folder is different--very different--from the real ones. Applications that have been deleted are still in there (and not marked as deleted), while some that should be there are missing.

There are 4 different types of discrepancies (screenshots below show the first two):

1. Deleted Applications still shown as active

"1Password 6", "3DGallery", "A Better File Rename 10", "Adobe Digital Editions", "Adobe Digital Editions 4.5" are all gone from my system, but QR "thinks" they are current.

2. Active applications shown as deleted

1Password is marked as deleted in QR, but in fact it's active.

(note: 1Password and "1Password 6" are the same thing, except the former is from the App Store. I bought from the App Store--a decision I regret, btw--and downloaded 1Password 6 from their website while it's in beta. Changed back to the App Store version when it's officially released.)

3. Active applications not backed up

4. Applications contents not updated

I let QR to recall the whole Applications folder to a different location and did a full binary comparison. Many files are different. The most current backup was captured earlier this morning (at 3am), and that's the one I recalled. I certainly haven't installed or updated anything since then, and some applications haven't been used for days if not weeks. MAS auto update is turned off on my system, and those applications are not running in the background.

My system is El Capitan 10.11.3.

James Bucanek wrote:This should be fixed in 2.0.0b26 (just released).

Indeed. Many thanks!

James Bucanek wrote:What exactly do you mean by "it didn't work"? Looking at the logs, I don't see anything that would indicate a problem opening the archive. Was the window just blank? Was it taking forever to display the layers? ... ?

Sorry for not making it clear in the first place: by "it didn't work" I meant nothing happened after I double-clicked the archive in the "Open Archive..." dialog (or clicked the "Open" button after selecting the archive). The dialog would close and that's it. Nothing else happened.

Tried it a few times just now, and made sure to wait more than 15 min. for it. Still nothing. Had to double-click in the Finder to open in able to conduct the next test. If a stale lock is the cause, wouldn't it also prevent the archive from opening right away from Finder?

Be patient. Once an archive acquires an orphaned access lock, it take a while for QRecall to determine that the lock is stale and reset it. It does this automatically, but it takes about 10 minutes for QRecall assure itself that there are no other processes accessing the archive at a the same time.

OK, I tried to delete an item in the archive just now, and have been patiently waiting for it. More than 15 min. time has passed and QR is still "waiting for archive".

A different message did came up (replacing the "waiting for archive" message) for a split second, too short for me to read it as "waiting for archive" reappeared right away.

I suspect all is well now. You waited the magic 10 minutes for QRecall to determine that it was safe to access the archive. Once it had, the access lock for the archive was reset and actions will now proceed normally.

Unfortunately, no. I conducted several tests after the successful compact action last night before reporting. Did the same this morning.

While "waiting for archive" when trying to delete an item, an event-driven capture to the same archive was triggered. That action had to "wait for archive" as well, so I stopped the new (capture) action. That gave me an idea: after canceling the delete job and quitting QR to close everything, I reopened QR and made a manual capture from the Actions window. The capture waited about 5 min. before going into action. The is probably due to the stale lock you mentioned.

The next capture would go swiftly as usual, so the stale lock should have been cleared. Still can't open the archive from the "Open Archive..." dialog.

Forgot to add (though you might have guessed): no other archive has the issue. This archive is not large (some others are much larger), currently taking up 7+GB, but it has the greatest number of layers (135 and counting), if that matters.

QR2 beta 25 on El Capitan 10.11.1.

Today when trying to open an archive from "File - Open Archive ..." dialog, it didn't work (it's been a while since I last opened the archive, so it's no longer on the recent archives list). Double clicking on the archive in Finder did work, but then it can't be closed, either by clicking on the window control button or with the "File - Close" command (or cmd-W, for that matter). Had to quit QR to close it. I've tried it several times with the same result. I even tried it once on another desktop (running the same beta version, but on Yosemite); same result.

The problem is not limited to opening and closing. I can't delete any item on it, nor can I remove any layer, merge layers, compact the archive or combine volumes. (The archive has two volumes of the same source directory after I installed El Capitan, so I want to combine them.) The action would appear to be starting, but would be "waiting for archive" to no end.

After clicking "Stop" to cancel the action, there's an entry in the log that says "Problem encountered while closing archive", so it appeared to be related to the closing problem after all.

Verifications (numerous times) found no error. Regular captures seem to be fine as well. I also successfully compacted it from the Actions window without opening the archive, but the action waited more than 10 min. before really doing anything.

A diag report has been filed.

I ran into two small issues when trying to restore the whole system partition with QR 2.0 beta for the first time yesterday. The restoration was done from a standby system (a bare minimum El Capitan system with QR 2.0 b23 and some other essential utilities installed) as I intended to restore the whole system partition.

The restoration was mostly successful, but QR said it failed at the end. The log registered two errors:

Action	2015-11-27 12:53:00	       	  Recall issues

Action	2015-11-27 12:56:57	       	    volume carlosys

Action	2015-11-27 12:56:57	       	      Applications

Action	2015-11-27 12:53:00	       	        folder CrashPlan.app

Action	2015-11-27 12:53:00	Caution	          Stopped processing folder

Action	2015-11-27 12:53:00	       	            unable to set attributes

Action	2015-11-27 12:53:00	       	              Type: directory

Action	2015-11-27 12:53:00	       	              Path: /Volumes/carlosys/Applications/CrashPlan.app

Action	2015-11-27 12:53:00	       	              Name: CrashPlan.app

Action	2015-11-27 12:53:00	       	              ErrDescription: Operation not permitted

Action	2015-11-27 12:53:00	       	              attributeSet: 0x00020f00

Action	2015-11-27 12:53:00	       	              POSIXErr: 1

Action	2015-11-27 12:56:57	       	      Users/wang

Action	2015-11-27 12:56:40	       	        folder Documents

Action	2015-11-27 12:56:40	Caution	          unable to remove access control list

Action	2015-11-27 12:56:40	Minutia	            POSIXErr: 22

Action	2015-11-27 12:56:40	       	            ErrDescription: Invalid argument

I tried to restore again for the user profile folder (Users/wang) and this time QR made no complaint. Trying to do the same with the CrashPlan.app however ran into the same issue. I ended up reinstalling CrashPlan after booting into the restored system.

The system has been running smoothly after restoration so there should be no problem. But I guess I should report the incident back to you. A diag report was filed right after the failure yesterday.

Thank you. The old, problematic system archive of mine is now back in service.

James Bucanek wrote:I do have one more question: did you unmount the volume (mount point) at ~/Documents before you made the capture, or before you performed the verify?

Sorry for not making it clear earlier. By "trying again after unmounting the ~/Documents partition" I meant the whole thing: creating a new test archive, capturing my user profile directory tree, and then verifying the archive.

As I mentioned earlier, only the archive in charge of backing up my system partition would fail to verify, and it is so even after I started over with a brand new archive.

After some digging just now I found my user profile folder was the culprit. Now, remember I said I had a dedicated partition for my documents which is mounted at boot at ~/Documents? I unmounted the partition and tried again and sure enough the test archive verified without error.

Note that I've been using the same arrangement for a long time and neither QRecall v1.2.x nor early v2 betas had any trouble with it. They only started since beta 16, or 15 at the earliest.

A diag report has been filed.

Strange! I sealed the old sys.quanta and created a new one, which had its first capture last night (at 3am this morning), and then immediately failed the verification less than 2 hours later. It's repairing; a diag report will be sent when done.

edit: the repair job checked the partition hosting the archive: no problem. I also verified my system partition with Disk Utility: no problem either.

The verification failed again today with "layer catalog tree" error as you mentioned. It's fine now after reindexing with the newest layer (created last night) intact. I'm going to seal the archive and start a new one for the time being. The old archive would be kept for a while so it would be available for testing if you find a solution.

I keep old system archives to satisfy my occasional curiosity when I want to see how something was done/set back then, and for the rare cases where I want to check an old plist or the like when investigating an issue. Nothing critical. To resuscitate the system, a recent archive suffices.

What worries me are my other archives, which hold my actual "data" and were all created by QR v.1.2.x. Weekly verifications have all checked out just fine so far, but do you advise starting anew with those as well?

Something just came to mind, though I don't know if it bears any significance to the issue.

I have a SSD partition dedicated for my documents, which is mounted at boot as the "Documents" folder under my user profile. As a result, while sys.quanta (the archive at issue) is set up to capture only the system (root) partition, it doesn't backup the contents of the ~/Documents folder, which is backed up separately.

Sys.quanta, however, does show two "volumes" when opened in QRecall: "carlosys" (the name of my system partition) and "Documents", as shown in the attached screenshot below. Note that the size for the "Documents" volume is zero. It really is an empty volume.

James Bucanek wrote:Important question: Is this an archive created with the 2.0 beta, or is this a 1.2.x archive that you started using with 2.0?

The latter. The date stamp for layer 0 is 2015-01-31, so definitely 1.2.x.

Did a manual capture just now, followed by verification, and sure enough, the verification failed again for the same reason. It's repairing. I'll send another diag. report when it's done.