QRecallDownloadIdentity KeysForumsSupport
  [Search] Search   [Recent Topics] Recent Topics   [Hottest Topics] Hottest Topics   [Groups] Back to home page 
Messages posted by: Johannes
Forum Index » Profile for Johannes » Messages posted by Johannes
Author Message
James,

thanks for the quick answer.

James Bucanek wrote:First, please send a diagnostic report. I'd like to look at the whole log.

Sent.

since prior to 1.2.0(58) it wasn't possible to have a pre-authorized helper installed in a home folder that was on another volume.

I am quite sure that I was able to pre-authorize and that I was prompted to re-pre-authorize after each new beta in last year. (But maybe QRecall was actually only pretending to be pre-authorized - or it was possible under Snow Leopard. I switched to Lion two weeks ago)

The second, far more serious, problem is that your scheduler is the wrong version.

After I created /Library/Application Support/QRecall manually as mentioned in my original post I got no further "Scheduler version mismatched" entries.

My guess is that you pre-authorized QRecall to use administrative privileges at some point in the past, and then selected the option to run actions when you are logged out.

Yes to the former. No to the later (if I remember right)

Note that in this situation QRecall should have informed you that it needed to install the scheduler;

I'm not aware of getting any dialog related to this.

To fix this:
...
- Reauthorize QRecall.

I followed your steps. But Reauthorizing was not necessary after restaring QRecall (the button reads "Cancel Preauthorization")

But I noticed that /Library/Application Support/QRecall was not recreated and the log says again "Cannot create support folder". I'll send a second diagnostic report that includes the fixing attempts.

Johannes

I have my long-term Archive on external disk A along with other backup stuff. This disk A is cloned to disk B for off site storage.
When I connect Disk B QRecall's Actions start capturing to the cloned Archive. While this makes some sense (the Archives on both disks are identical after all) and there's no harm in a capture, there might be issues I'm not aware of.

Things seem to change with beta 1.2.0.57/58: The status window clearly distinguishes between the Archive on disk A and its clone on disk B. They show up as different archives with different status (as there was no verify on disk B yet).

This is at least confusing. I would prefer QRecall's actions to leave the clone alone.

But maybe my clone strategy is simply not compatible with QRecall's philosophy. What would be your advice?

Johannes
When updating to Version 1.2.0(57/58) I first noticed that the new status window does not come up when selecting Window>Status. The menu bar item also did not contain an entry "Status Window". I was busy so I did no further investigation or reporting.
After a few days I noticed a couple of entries in the log:



I found the reason in this message:

After copying the contents of ~/Library/Application Support/QRecall to /Library/Application Support/QRecall everything seems to work fine again. So the whole report is meant to let you know that there was some issue.

I'm using OS 10.7.2. My home folder is on a separate volume on the same disk as the boot volume. Not sure whether this is related to this thread: http://forums.qrecall.com/posts/list/375.page. But in my case I had no problem prior to 1.2.0(57/58).

Hope this makes some sense to you.

Johannes

Oh, one more thing ...

... can we get "run Action" with a submenu of all actions as well?
Would be very handy!

Johannes

Johannes
Thanks for the Update.

My favourite new feature is the menu bar item.
Would it be possible to get a "Suspend all Schedules"/"Resume Schedule" item there? And of corse some indication in the icon that the actions are suspended?
I do audio recording and don’t want QRecall getting busy on disks while I need every pipeline to get the audio through. This would be handy for any disk-re-organisation or cloning operations too.

Johannes
James Bucanek wrote:I have to say that the Finder's approach, while somewhat inconsistent, has merit and wouldn't be terribly difficult to emulate in QRecall.

Having thought about this for some days now, I would say: going with Finder behaviour might be the best for most users. Although I personally would like to always maintain selection, because when I switch views, the reason is that I want to do/see something in the other view with the selected item, that is not possible in the current view.

But while thinking about all this nice views and navigation between them, it came to my mind, that what ever road the the final UI will take, I will probably not see much of it. I rarely need to find and recall something from backup. If navigating is not exactly my personal taste, it won't trouble me often.
The missing AppleScript Trigger hits me more often. So: don’t waste too much time on the views

Johannes
Just for the records: revealing an item via Service or Spotlight brings up QRecall but not the item. I guess this is related to the not yet implemented search.

Johannes
It happened several times now that I opened an Archive and QRecall picked up the last view and root (column view) with the the top level item selected. The second column would reading "collating …" and thats it. The interface would not respond to anything. I can close the window (red close button). After that Spinning beach ball and only chance to get any further is force quit.
Console says:

3.5.11 19:04:00 QRecall[428] *** Assertion failure in -[PackageNames nameOfPackage:], /Users/james/Development/Projects/Quantum Recall/Common/Source/Repository/Names/PackageNames.m:408

Johannes
James Bucanek wrote:When switching between views, the root folder should remain the same and QRecall will attempt to preserve the current selection. Now there are obvious limitations, as some views (like list and column) can select nested sub-items that can't be represented in other views.

Okay I think that was the point that confused me. I tried to check the behaviour systematically and all the time, when it "did not work" it was a selection in list or column view somewhere down the hierarchy. So it seems to behave accordingly to your programming. No bug then, but different philosophy than expected

Personally I would prefer this: preserve selection and change the root (or unfold) if necessary. But I have no idea what to do with cross folder selection in list view when switching.

I admit: what ever you do, it will compromise something and it is difficult to decide what.

I will have to do some meditation on this …

Johannes
One more suggestion on the path navigation placement:
Place the history arrows and an "up" Button at the left side between layers and browser. This would not obscure the time lines and help all users like me that tend to search at the top of the browser to navigate. Because that is mainly what I want: go back in history or up. Wait: Is there a situation where the back button would not simply go up? If not we can drop the up-Button.
The Navigation bar for big jumps would remain at the bottom.

Johannes
James Bucanek wrote:I struggled with that myself. The problem is that if you put the path control above the item pane, it ends up between the item browser and the layers. The interface is already pretty busy there, and it gets obscured by the timelines. If you put it at the very top, now it's well away from the item views and feels disconnected from it.

You are right. Leave it at the bottom.

The individual item playback controls have not been (re)implemented. I was debating whether to keep them or not. With the ability to automatically hide uninteresting layers, their utility is considerably lessened. As an alternative, I've considered a keyboard short-cut that hides/reveals the layers based on the currently selected items.

The Problem is that there is no obvious way to select an instance in the past. With the shortcut you still have the last instance selected and you need to start shading layers in a second step. Maybe (double-)clicking on the block-mark in the timeline could shade to that layer?

42

Now we only need to know what the question was

If you select a file from layer 4 and a folder from layer 19, there's no way for QRecall to frame that selection in terms of a single operation.

The easiest and most user friendly way would be to restrict selection in the time view to one item (or items within on layer).

But just like the playback controls, it would also be easy to create a short-cut that would let you click on an item in the time view and automatically shade the layers so that the item you clicked on is now the latest item, ready to be recalled or restored.

In this view the shortcut is useful. (Because it is the only view where you can select an item in the past directly.)

Too more things:
- I miss a toolbar item for instant recall
- I would prefer if switching browsers-styles would retain root, selection and layer shading

Johannes

I played a little bit with the new views. My favourite is the column view, but I enjoy the time view as well. I think each view has its strength and it is good to have options.
I also like double click to root a folder and the new behaviour when opening a folder triangle in list view.
Nice work.

Some observations:
- I find myself always looking up when searching for the path bar. I know the Finder has it on the bottom too. But for me the top of the browser feels more natural.
- Hoovering over a dot in the browser no longer displays the Playback controls. Are they simply not jet implemented or is there a new way to reveal previous/next captured instances?
- What is the meaning
- Hiding irrelevant Layers is a good idea. But I would suggest to place the Show hidden layers command in the layers menu as well.
- In time view I can't select a certain instance in time. QRecall always selects all instances (the whole lance of pierced instances). When I ercall I get the last captured instance.
- What is the meaning of the different colours of the layer labels in time view?

Johannes
Well, that's exciting news!

Johannes
There seem to be lot of surprises in the deep dungeons of my files. Today I tested a restore scenario and QRecall stopped and the logs says that for a couple of files some properties could not be restored due to insufficient privileges (I run without authorising because the folder only contains my stuff). I was surprised because QRecall was able to capture the file without admin privileges.

I checked the files (All some gif files downloaded from the internet a few month back) and it seems that they all have "wheel" as group instead of staff (for whatever reason).

ls for the original:


ls for the recalled version:

(The Info window in Finder lists no group at all)

It seems all I lost is group and world access and the original date. And I have some finderInfo attributes out of midair:

Strange thing.

For the records: I tried the same with Time Machine. It simply stops restoring when it comes to the first problematic file proclaiming about privileges. Bad. Interestingly Time Machine has the original Wheel privileges in its belly.

QRecall on the other hand simply went on, recalled all files nicely and informs me after that about a possible problem. Good!

Johannes
 
Forum Index » Profile for Johannes » Messages posted by Johannes
Go to:   
Powered by JForum 2.1.8 © JForum Team