https://forums.qrecall.com/hottestTopics/list.page JForum - http://www.jforum.net https://forums.qrecall.com/posts/preList/252/1534.page https://forums.qrecall.com/posts/preList/252/1534.page GMT
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.]]> https://forums.qrecall.com/posts/preList/144/704.page https://forums.qrecall.com/posts/preList/144/704.page GMT
Thanks for the explanation...makes sense...

So far...the 2 separate capture actions seem to be doing the job well...

Thanks again for all your help on this issue.

Thanks,

GKG]]> https://forums.qrecall.com/posts/preList/274/1291.page https://forums.qrecall.com/posts/preList/274/1291.page GMT
While this changes nothing enabling QRecall to back up to Amazon S3, it is significant for those who'd like to back up QRecall [i][b]archives[/b][/i] to S3.

Best,
]]> https://forums.qrecall.com/posts/preList/91/715.page https://forums.qrecall.com/posts/preList/91/715.page GMT Yes, I got the logs. I just haven't had a chance to look them over yet.

[quote]Also I am trying capturing something from OS X now, the volume that was giving us trouble.[/quote]
Keep us posted... :)]]> https://forums.qrecall.com/posts/preList/72/308.page https://forums.qrecall.com/posts/preList/72/308.page GMT
I don't see any differences in the ownership or permissions for the two archives, and I don't see any stale .lock or .share files that might be blocking access to it.

So, the only thing I can think of at this point is that the file server supports file locking and/or advisory locks and is holding an orphaned lock on one of the files in 3rd backup.quanta. This can happen when a network clients obtains a lock on a file and then gets disconnected from the server.

This can usually be solved by restarting the server. If this is a network device that runs 24/7, it's easy for orphaned locks to stay around for weeks. (Note that in cases like this, restarting the clients won't have any effect on the problem.)

If that doesn't work, you can try repairing the 3rd backup archive (presuming you have enough free space), choosing the "Copy recovered content to new archive" option (say 4th backup archive). QRecall will extract all of the data in the original archive and use it to create a brand new one. When finished, you can discard the old archive.]]> https://forums.qrecall.com/posts/preList/619/2947.page https://forums.qrecall.com/posts/preList/619/2947.page GMT
You are correct...no surprise. :-o

When the Capture action to the archive stored on the SMB mount point fails, the archive is left damaged...and must be repaired first. This was automatically happening before...since I always ran a Verify action after the Capture failed...and the Verify fixed the archive's data component.

My error, in this case, was attempting to reindex of the archive before manually repairing it...(or running a Verify)...and it, therefore, failed, as you stated because the data was damaged by the Capture.

I repeated my steps...after first copying a clean archive to the SMB share...

1) Running a Capture...which failed.
2) Repairing the now damaged archive on the SMB share
3) Deleting all the .index files in the package
4) Reindexing the archive...which did work fine.
5) Trying another Capture...which failed.


So...at this point, I believe it is still only the Capture that has the issue to the SMB share.]]> https://forums.qrecall.com/posts/preList/361/1891.page https://forums.qrecall.com/posts/preList/361/1891.page GMT
thanks for your patience. Since i am currently running out of time, i can't stay with QR. I will revert to my old solution and check back to QR in about half a year to see if it has made steps into the right direction.

Best Regards
Jan
]]> https://forums.qrecall.com/posts/preList/47/155.page https://forums.qrecall.com/posts/preList/47/155.page GMT
Thanks for sending me your files. They didn't include any crash logs, but after reviewing your log files I don't think you have any.

The only instance of a "lost connection" error was recorded on April 4. (If you want to to look further back, send me some older log files). Most notable is this log entry:

[code]2009-04-04 05:16:21.946 -0500 #debug# VerifyCommand listeners probably dead, terminating process[/code]
It appears that the listener process (the Activity Monitor window) was simply running too slowly to keep up with the action's updates. The inter-process equivalent of the spinning beach-ball cursor.

What happens when an action is done is that it sends all of its listeners a message that it has finished. It then waits around for about a minute for those listeners to acknowledge that it's done and close their communications connection. If the listeners don't, the action process assumes that they died and just terminates. That's what is recorded in your log. But, if it turns out, the listeners weren't really dead, they may attempt to communicate with the action process again, which fails because that action no longer exists. This results in a "lost communication with helper" error.

Since I don't see any other errors or problems in your log, I'm confident that this was a harmless, and sporadic, communications failure between processes and not a failure of the verify action that was running at the time.

]]> https://forums.qrecall.com/posts/preList/96/891.page https://forums.qrecall.com/posts/preList/96/891.page GMT That's a huge relief. :-)

[quote]One very minor point, the Activity Monitor tells me that the next run is 'today' quoting a time that has already passed. Ideally it should say 'tomorrow' in this situation.[/quote]
It's a known bug in the monitor. In some circumstances it's not updating its display when the schedule changes.]]> https://forums.qrecall.com/posts/preList/77/328.page https://forums.qrecall.com/posts/preList/77/328.page GMT
Ralph]]> https://forums.qrecall.com/posts/preList/115/508.page https://forums.qrecall.com/posts/preList/115/508.page GMT https://forums.qrecall.com/posts/preList/1354/10173.page https://forums.qrecall.com/posts/preList/1354/10173.page GMT
Mostly minor bug fixes, but if you're using it you'll want to update.

See the release notes at [url=http://www.derman.com/blogs/QRecall-Backup-Sets]http://www.derman.com/blogs/QRecall-Backup-Sets[/url].]]> https://forums.qrecall.com/posts/preList/527/2738.page https://forums.qrecall.com/posts/preList/527/2738.page GMT
Some diagnostic reports (Help > Send Report, in the QRecall application) sent in the past week were successfully uploaded to our report server, but failed to be forwarded to our problem tracking database and have been lost forever. :(

So if you sent a report during the last week of January or the first week of February, 2020, and have not gotten a response, either send another report or contact [url=mailto:support@qrecall.com]support[/url] about your issue.

We apologize for any inconvenience.]]> https://forums.qrecall.com/posts/preList/1796/4968.page https://forums.qrecall.com/posts/preList/1796/4968.page GMT Your choice!

As you observed, QRecall's data de-duplication means that capturing the new volume to your existing archive won't make it much bigger because most of the new volume is a copy of what's already been captured.

The question is really, do you want to keep the history of changes from your old system? If so, then keep the archive. You'll end up with an archive that has two volumes, which you can then use the Combine Items command to stitch into a single volume so you keep an unbroken history of your files.

If you really don't need that history, proceeding with a new archive makes for a clean start.

Enjoy!]]> https://forums.qrecall.com/posts/preList/637/6624.page https://forums.qrecall.com/posts/preList/637/6624.page GMT
Send a diagnostic report ([b]QRecall > Help > Send Report...[/b]) and we'll investigate further.]]> https://forums.qrecall.com/posts/preList/569/2903.page https://forums.qrecall.com/posts/preList/569/2903.page GMT I?m pleased to write that QRecall development is?once again, thankfully, finally?in high gear.

I'm putting the final touches on the command line tool, which does a lot more than I orignally planned.

I have some new scheduling logic/features that I want to get working before I release it as a beta, along with some massive UI code clean-up to do.

There are also a bunch of random problems, glitches, and crashes that I?m still hunting down. Consequences of all that new code. *sigh*

And I have more testing to do. QRecall needs to be really stable before I spring the next version on my loyal users. This version will NOT be backwards compatible with earlier versions. Once you capture new data using 2.0, you can?t open that archive with an earlier version. So early adopators need to know they?ll be flying without a safety net...]]> https://forums.qrecall.com/posts/preList/441/2289.page https://forums.qrecall.com/posts/preList/441/2289.page GMT
Will let you get on then and concentrate on coding rather than answering my forums posts :)

cheers
Paul.]]> https://forums.qrecall.com/posts/preList/611/2969.page https://forums.qrecall.com/posts/preList/611/2969.page GMT
To give you an example, when you download a file from the Internet in OS X 10.5 (Leopard), a tiny chunk of data is attached to the file with the name "com.apple.quarantine". com.apple.quarantine is an extended attribute attached to the downloaded file. Whenever you open a file or application that has a com.apple.quarantine extended attribute, the Finder will warn you that you're about to open something downloaded from the Internet. If you say that's OK, the com.apple.quarantine extended attribute is removed.

Tiger had the ability to use extended attributes, but made little or no use of them. Leopard has begun to make use of extended attributes and their use is growing daily, both by Apple and third party applications.

Other examples: The extended attribute "com.apple.metadata:kMDItemWhereFroms" records the URL where an item was downloaded from. The "com.apple.TextEncoding" extended attributes identifies the encoding of a text file so the application doesn't have to guess. "com.apple.diskimages.recentcksum" records checksum calculations which help disk images mount faster.

Some extended attributes, like "com.apple.FinderInfo" and "com.apple.ResourceFork" mirror legacy item metadata (which QRecall already captures).

You can see the extended attributes of an item using the -@ switch of the ls command (in conjunction with the -l switch). So, to see the extended attributes of the items in your Documents folder, open up a Terminal window and type

[code]ls -l@ ~/Documents[/code]
Note: I've uploaded a newer version of the QRTouchXAttrItems tool that does a better job of ignoring extended attributes that QRecall already captures.]]> https://forums.qrecall.com/posts/preList/151/657.page https://forums.qrecall.com/posts/preList/151/657.page GMT
[u]Note: QRecall 2.0 makes most of these settings available in the [b]Advanced[/b] tab of the QRecall preferences pane. If running QRecall 2.0 or later, first check the [b]Advanced[/b] tab for the setting you are interested in. Refer back here if you don't find it.[/u]

These special settings can be set using the [b]defaults[/b] command in a Terminal window. The basic form for setting a QRecall preference value using the defaults command is:

[code]defaults write com.qrecall.client key value[/code]where 'key' is the setting and 'value' is its new value

Deleting a setting restores that setting to its default. The command for that is:

[code]defaults delete com.qrecall.client key[/code]

The default for some settings are variable or change from one release to the next, so deleting a setting is different than simply setting it to the default value listed below.

These settings can also be set using the Property List Editor included with the Xcode tools. Edit the values in the [b]~/Library/Preferences/com.qrecall.client.plist[/b] file.

Some settings won't take effect until the next time the application is started or the action is run. For the most reliable results, change these values when the QRecall application is not running.

[b]QRMonitorSpacesJoinAll[/b]
Value: false or true
Type: Boolean
Default: true
Version: 1.1 and later
Example: [b]defaults write com.qrecall.monitor QRMonitorSpacesJoinAll -boolean false[/b]
Note: This setting is in the [u]com.qrecall.monitor[/u] domain.
QRMonitorSpacesJoinAll let you gain some control of how the QRecall Activity window is managed by Spaces. When set to true, QRecall forces the QRecall Activity window to appear in all spaces. When set to false, the activity monitor window exists in the first space it appears in and will switch back to that space when reactivated. This can be controlled by manually moving the activity window to another space or setting the preferred space for the activity window. To set the preferred space, do the following:
• Locate and select the QRecall application
• Right/Control+click on the application and choose Show Package Contents
• Locate the QRecallMonitor application, inside the Resources folder, inside the Contents folder
• Open the Spaces pane of the System Preferences
• Drag the QRecallMonitor application into the Application Assignments pane of the Space preference panel
• Select the space, or spaces, the QRecall Activity window will appear in

[b]QRCaptureFreeSpaceSweep[/b]
Value: false or true
Type: Boolean
Default: true
Version: 1.1 and later
Example: [b]defaults write com.qrecall.client QRCaptureFreeSpaceSweep -boolean false[/b]
QRCaptureFreeSpaceSweep can be used to disable Capture's search for free space in an archive following a layer merge or delete. Normally, each capture begins by locating all of the unused space in the archive. Setting this to false skips this phase of the capture. The advantage of turning it off is primarily performance at the expense of additional disk space. Not searching for free space makes the capture process run quicker and avoids fragmenting the organization of the archive. The disadvantage is that the archive will grow indefinitely until it is compacted. One obscure advantage affects the capture of very large files (like disk images) that get stopped before the capture completes. The next capture begins by freeing the partially captured data. Setting QRCaptureFreeSpaceSweep to false skips this phase, so the quanta from the partially captured item is still in the archive and will not need to be added again.

[b]QRAuditFileSystemHistoryDays[/b]
Value: 0.0 to 365.0
Type: Floating Point
Default: 6.9
Version: 1.1 and later
Example: [b]defaults write com.qrecall.client QRAuditFileSystemHistoryDays -float 13.9[/b]
Beginning in Leopard, OS X introduced Filesystem Events, which tracks changes on volume by folder. Filesystem event's folder change detection is not, however, foolproof. There are a number of obscure situations where the file system will not accurately report the changes on a volume. To guard against this, QRecall only trusts the operating system for a limited amount of time. After that (approximately 7 days) the capture will ignore the system and perform a deep, exhaustive, scan of the entire directory structure looking for changes. Once the deep scan is complete, QRecall will again trust the operating system's change detection for another 7 days. QRAuditFileSystemHistoryDays sets the maximum amount of time that folder change information is trusted. Setting it to 0.0 will ignore all folder change information and cause every capture to perform an exhaustive scan of the directory structure.

[b]QRCompactFreeSpaceRatioMinimum[/b]
Value: 0.0 to 0.9
Type: Floating Point
Default: 0.04
Version: 1.0.1 and later
Example: [b]defaults write com.qrecall.client QRCompactFreeSpaceRatioMinimum -float 0.15[/b]
The compact action will only compact the archive if the percentage of free space in the movable region of the archive (the portion of the archive that isn't already completely compacted) is equal to or greater than this value. A value of 0.125 would mean that the movable region of the archive must contain at least 12.5% unused space before a compact would commence. This setting prevents a compact from moving GBs of data to recover tiny amounts of free space. Setting the value to 0.0 will cause the compact action to perform a full compact of the archive every time it is run.

[b]QRLogCaptureDecisions[/b]
Value: false or true
Type: Boolean
Default: false
Version: 1.0 and later
Example: [b]defaults write com.qrecall.client QRLogCaptureDecisions -boolean true[/b]
Setting this value to true causes QRecall to log every capture decision it makes. A capture decision records the item and the reason QRecall decided to capture it. This can be useful for determining why a particular item is, or is not, being captured. This option can result in a [u]tremendous[/u] number of log messages.

[b]QRLogViewXtraDetail[/b]
Value: false or true
Type: Boolean
Default: false
Version: 1.0 and later
Example: [b]defaults write com.qrecall.client QRLogViewXtraDetail -boolean true[/b]
If set to true, the log window will include to additional levels of detail allowing you to review debug and internal application messages.

[b]QRRunningMakesSystemActive[/b]
Value: false or true
Type: Boolean
Default: true
Version: 1.0.1 and later
Example: [b]defaults write com.qrecall.client QRRunningMakesSystemActive -boolean false[/b]
If set to true, running actions periodically notify the system that the action is using the file system. This prevents the computer from going to sleep. This has the unfortunate side effect of waking up the computer's display if it was asleep. To prevent this, set QRRunningMakesSystemActive to false.

[b]QRNumberOfCPUs[/b]
Values: 1 to 16
Type: Integer
Default: actual number of CPUs
Version: 1.0 and later
Example: [b]defaults write com.qrecall.client QRNumberOfCPUs -integer 1[/b]
Many QRecall actions create multiple worker threads based on the number of CPU cores/processors available. If QRNumberOfCPUs is set, it will ignore the actual number of CPUs and use the number in the setting. See also QRMaxNumberOfWorkers.

[b]QRMaxNumberOfWorkers[/b]
Values: 1 to 16
Type: Integer
Default: 6
Version: 1.0 and later
Example: [b]defaults write com.qrecall.client QRMaxNumberOfWorkers -integer 3[/b]
The maximum number of worker threads an action will create. The number of worker threads an action will create to process data in parallel will be either the number of CPUs or this setting, whichever is smaller. See also QRNumberOfCPUs.

[b]QRPhysicalMemoryMB[/b]
Value: 256 or greater
Type: Integer
Default: actual amount of physical RAM
Version: 1.0 and later
Example: [b]defaults write com.qrecall.client QRPhysicalMemoryMB -integer 6144[/b]
Amount of physical memory QRecall assumes is available for caches and buffers. If you want QRecall to use less memory (at the expense of efficiency and possibly additional I/O), set this to a lower value and QRecall will attempt to keep its memory use within this limit.

[b]QRNewDirectoriesOwnedByEUID[/b]
Value: false or true
Type: Boolean
Default: false
Version: 1.0 and later
Example: [b]defaults write com.qrecall.client QRNewDirectoriesOwnedByEUID -boolean true[/b]
If set to true and QRecall is authorized to use administrative privileges, folders created during a recall initially belong to the super user (root). Once the contents of the folder have been recalled, its owner and permissions are restored to their original state. However, this tends to confuse the Finder and will often result in a folder you can't open even though you have access to it. (Restarting the Finder will fix this.) If set to false, the folder will initially be owned by the user recalling the item. This can temporarily provide access to items belonging to other users. This feature has security implications and system administrators who worry about such things may want to turn QRNewDirectoriesOwnedByEUID on.

[b]QRFilePreallocateDisable[/b]
Value: false or true
Type: Boolean
Default: false
Version: 1.1.4 and later
Example: [b]defaults write com.qrecall.client QRFilePreallocateDisable -boolean true[/b]
During actions that increase the size of the archive, QRecall will normally reserve (preallocate) space on the drive to ensure that it has enough disk space to successfully close the archive. Setting QRFilePreallocateDisable to true disables this feature. See the QRFilePreallocateBugWorkaroundRule setting.

[b]QRFilePreallocateBugWorkaroundRule[/b]
Value: 0, 1, or 2
Type: Integer
Default: 0
Version: 1.1.4 and later
Example: [b]defaults write com.qrecall.client QRFilePreallocateBugWorkaroundRule -integer 1[/b]
Some versions of Apple's file system have a bug in the pre-allocation API that causes it to allocate much more disk space than was actually requested. If the drive is less than half full, the operating system may attempt to allocate all of the remaining disk space, resulting in an erroneous "disk full" error. A workaround for this bug is implemented in QRecall. It uses regular file allocation to simulate pre-allocation. When QRFilePreallocateBugWorkaroundRule is set to 0, QRecall uses its workaround when running on specific versions of Mac OS X known to have this problem. Unfortunately, if your archive is on a networked volume the file server may, or may not, have this same bug—QRecall cannot automatically detect this. Setting QRFilePreallocateBugWorkaroundRule causes QRecall to either always (1) or never (2) use the workaround. QRFilePreallocateBugWorkaroundRule is ignored if the QRFilePreallocateDisable setting is true.

[b]QRVMSwapStorePath[/b]
Value: Absolute POSIX directory path
Type: String
Default: /var/vm
Version: 1.0 and later
Example: [b]defaults write com.qrecall.client QRVMSwapStorePath '/Volumes/Swap/vm'[/b]
QRecall never captures the virtual memory swap files of the booted system. It determines the location of those files by examining the command arguments of the [b]dynamic_pager[/b] daemon. If you have customized the location of the system swap files, QRecall may have difficulty determining their location. Set QRVMSwapStorePath to the absolute POSIX path of the directory that contains the swap files.

[b]SUFeedURL[/b]
Value: URL
Type: String
Default: Current Update Feed URL
Version: 1.0 and later
Example: [b]defaults write com.qrecall.client SUFeedURL 'http://www.qrecall.com/release/appcast-alpha10.jsp'[/b]
QRecall will periodically query this URL to check for updated versions. During development, alternate application feeds may be made available to alpha and beta testers. These users will receive updates that the regular users don't. If you participate in one of these programs, you will be given an alternate URL to set. Deleting this setting will return to the standard application update feed.]]> https://forums.qrecall.com/posts/preList/66/245.page https://forums.qrecall.com/posts/preList/66/245.page GMT
Included in the book is a 40% coupon off your next QRecall identity key purchase, a $16 value.]]> https://forums.qrecall.com/posts/preList/452/2130.page https://forums.qrecall.com/posts/preList/452/2130.page GMT Short answer, yes. This has been on the to-do list for quite some time, it?s urgency has just never risen near enough to the top to actually get implemented. I?ll give it a nudge upwrards.

[quote]2. May I also second Norbert Karl's suggestion (May 2013) about allowing more flexibility in the delays imposed before a QR Action starts that is keyed to archive-volume connect?[/quote]
This has already been added to QRecall version 2.0, along with new action events. In 2.0 you will be able to delay the start of any event action from between 1 and 999 minutes.

[quote]QRecall is a wonderful tool. Thanks for making it available?and for your work in supporting us out here.[/quote]
You?re most welcome.]]> https://forums.qrecall.com/posts/preList/480/2251.page https://forums.qrecall.com/posts/preList/480/2251.page GMT
Betas are pre-release versions of QRecall, providing you with early access to new features and bug fixes. As with most betas, the following disclaimer applies:

[quote]A beta release is a work-in-progress. While every attempt is made to ensure that data integrity and compatibility between releases is maintained, there are no guarantees. Please use beta releases with a reasonable amount of caution and promptly report any bugs or anomalies you discover.[/quote]
Here's some things about a beta release that you should know:

- Documentation for new features is often missing. If you have a question about how a new feature works, ask about it in the discussion forum.

- Please don't be shy about feedback! We honestly want to know how you are using QRecall or maybe why you are not using QRecall. We want to know what features you like, dislike, or think could be improved.

- Set QRecall's auto-update feature to check for new versions daily or weekly. Beta versions expire within a month or two of being released. The auto-update feature is the best way to keep up with new releases.

Dawn to Dusk Software is dedicated to making QRecall the premier disk-to-disk backup solution for the Macintosh. We sincerely appreciate your participation in this public beta.

Enjoy,

James Bucanek
]]> https://forums.qrecall.com/posts/preList/6/7.page https://forums.qrecall.com/posts/preList/6/7.page GMT
Ralph]]> https://forums.qrecall.com/posts/preList/89/2899.page https://forums.qrecall.com/posts/preList/89/2899.page GMT Ah, that's the problem.

QRecall and FileVault don't play well together. It seems as though every security measure Apple adds to OS X in general, and FileVault in particular, breaks something in QRecall. :( Don't get me wrong; I'm actually big fan of OS X's security model, it just sometimes makes life hard for us legitimate developers.

My best suggestion is to uninstall QRecall in your current account, create a second admin account (if you don't have one already), and install QRecall there. Set it up so that actions run when logged out, then schedule the capture actions to run when you'll be logged into your FileVault account.

I had QRecall working with FileVault for awhile, but recent changes have broken that again. I have a to-do item to revisit FileVault compatibility, but I've put it off until I've added encryption to QRecall archives—users that are encrypting their home folder generally don't want an unencrypted copy setting on an external drive. As a workaround, I do have a few users who store their archives on encrypted disk images or hardware encrypted hard drives.]]> https://forums.qrecall.com/posts/preList/297/1386.page https://forums.qrecall.com/posts/preList/297/1386.page GMT
A new beta program for QRecall 1.3 will begin soon.]]> https://forums.qrecall.com/posts/preList/251/1906.page https://forums.qrecall.com/posts/preList/251/1906.page GMT
I had decided to leave the volume as is, but an itch made me give APFS one final chance. This time, I erased the whole drive (yesterday I merely reformatted the APFS volume without touching the container/partition). I'll report back if I find something interesting.]]> https://forums.qrecall.com/posts/preList/913/3670.page https://forums.qrecall.com/posts/preList/913/3670.page GMT Today we're pleasantly surprised.

QRecall version 1.0.0(48) is Leopard (Mac OS X 10.5) ready. I was seriously concerned that some portions of QRecall would require major changes in order to get it to work under Leopard. As it turns out, a couple of elegant and straightforward solutions were found.

Choose [b]QRecall > Check for updates...[/b] to get the latest version.

The details of the changes can't be discussed until Leopard is officially released.

Caveat: While we've encountered no significant issues with QRecall running under Leopard, testing has been extremely limited and confined to the last Leopard seed released to developers. It has not yet been tested on the final release of Leopard. I'd like to remind everyone that QRecall is still beta software (even more so under Leopard); Please use it cautiously and report any problems you encounter.]]> https://forums.qrecall.com/posts/preList/75/285.page https://forums.qrecall.com/posts/preList/75/285.page GMT When the laptop wakes up again, it becomes a race condition between the TCP/IP stack trying to reconnect with the server and reestablish the session it had and the next filesystem request timing out. The filesystem tries to give the network stack time to recover, but it doesn't always happen that way.]]> https://forums.qrecall.com/posts/preList/465/2205.page https://forums.qrecall.com/posts/preList/465/2205.page GMT You're right. As ever my maths missed out some zeros. Now that the verify is finished I find that a 450+ GB archive took just under 20 hours to verify. This (re)calculates to just over 6.4 MB/sec.

[quote=James Bucanek] Verifies are I/O bound. If you have 100Mb ethernet, connecting via ethernet will give you about 10MB/s. If you have Gb ethernet, you should get about 80-100MB/s.

I don't know what your topology is, but consider having a different computer verify the archive. I have several laptops and an iMac that all capture via WiFi, but I use the server that's connected directly to the shared RAID to perform all of the weekly verify and merge actions. Everything is fast.[/quote]
Good idea, I'll try to organise a spare laptop to do the 'heavy lifting'.]]> https://forums.qrecall.com/posts/preList/457/2172.page https://forums.qrecall.com/posts/preList/457/2172.page GMT
If not, send a diagnostic report (Help > Send Report) and we'll try to figure out what's going on.

]]> https://forums.qrecall.com/posts/preList/87/834.page https://forums.qrecall.com/posts/preList/87/834.page GMT
Thanks for the great feedback and suggestions. However, some of these ideas are at odds with QRecall's basic design and philosophy.

QRecall was designed to capture everything that's important, quickly and efficiently, and allow you either recover earlier versions or restore any item to the exact condition it was in when captured.

The filtering mechanism was designed [u]solely[/u] to avoid capturing superfluous or redundant files (cache, spotlight indexes, backup copies, etc.). It was not designed to micro-manage an archive, arbitrarily capturing this file but not that one.

Excluding important items from a capture creates a confusing middle ground that I'm not comfortable with. In your iTunes example, podcasts are excluded but you clearly don't want them erased. My question is "Which is it? Are the files important or not?" It would make sense to exclude them if you could easily re-download the lost podcasts. It would not make sense if you could not.

Taken to it's logical end, not capturing items and then not erasing those items during a restore would result in a mish-mash of interleaved versions. Simple examples would be backup files that are newer than the working version. Replacing some files but not others in an iTunes library will definitely cause iTunes to become confused. Or let's say you decided to reduce the size of your archive by excluding all foreign language resources from application bundles. Restoring an application package without deleting those excluded items would result in a Frankenstein mixture of old and new resource files. This could cause application instability or worse. If you did this to the operating system, the results would be disastrous.

Being be bit of a [url=http://en.wikipedia.org/wiki/Propeller_head]propeller-head[/url] myself, I'm all for giving sharp knives to those who want them. I am considering adding an "Overlay" command. This would be a restore that doesn't delete any existing files that do not appear in the archive; it would only recall deleted files and replace newer files with the version from the archive.

Combined with arbitrary rules for excluding items, you could (at your own risk) overlay a set of captured items on top of an existing set of files. (Note that you can accomplish this right now by recalling the items to a separate location, then merging the two directories with a little command-line work.)

[quote]I think we should always know exactly what is being backed up, and will be restored, and both these issues affect that.[/quote]
I agree—which is exactly why I don't like this feature. :wink:]]> https://forums.qrecall.com/posts/preList/52/229.page https://forums.qrecall.com/posts/preList/52/229.page GMT
This thread is closed.]]> https://forums.qrecall.com/posts/preList/81/337.page https://forums.qrecall.com/posts/preList/81/337.page GMT
If you back up laptops to separate archives it may still be possible to merge, verify, etc. those archive from a wired computer on the network. I'm not sure about that, though, since I don't do it that way.]]> https://forums.qrecall.com/posts/preList/483/2263.page https://forums.qrecall.com/posts/preList/483/2263.page GMT https://forums.qrecall.com/posts/preList/460/2190.page https://forums.qrecall.com/posts/preList/460/2190.page GMT
I've done what you said about reset TM, it worked for a day, then the next day it was back to normal.

Thanks !!]]> https://forums.qrecall.com/posts/preList/566/2877.page https://forums.qrecall.com/posts/preList/566/2877.page GMT https://forums.qrecall.com/posts/preList/598/2904.page https://forums.qrecall.com/posts/preList/598/2904.page GMT https://forums.qrecall.com/posts/preList/70/272.page https://forums.qrecall.com/posts/preList/70/272.page GMT
I would have been really interested in finding out exactly what file(s) were eating up all of your disk space. One of the usual suspects is the virtual memory store (as we've discussed), but cache and log files are also regular culprits.

If you suspect VM, that's easy to determine. Launch Activity Monitor and find the [b]Swap used[/b] amount in the System Memory category. Ideally, it should be less than the amount of physical memory you have.

If you're looking for large files anywhere, I find the [url=http://www.whatsizemac.com/]WhatSize[/url] utility particularly useful. I'm sure there are many other apps the perform a similar task, but this one has always been good to me.
]]> https://forums.qrecall.com/posts/preList/468/2222.page https://forums.qrecall.com/posts/preList/468/2222.page GMT
Thanks for the confirmation!

Look for a new release of QRecall that works around this issue.]]> https://forums.qrecall.com/posts/preList/1091/4036.page https://forums.qrecall.com/posts/preList/1091/4036.page GMT https://forums.qrecall.com/posts/preList/831/3486.page https://forums.qrecall.com/posts/preList/831/3486.page GMT Either way I am really looking forward to it.[/quote]
Rosco,

Like the Great Pumpkin, QRecall 2.0 will rise again.

I?m happy to report that I delivered the final chapter of my new book, Learn iOS 8 App Development, to Apress yesterday. I expect near-full-time development of QRecall to resume in a week or two. I?ll post something on the forums when the next beta looks close.]]> https://forums.qrecall.com/posts/preList/486/2274.page https://forums.qrecall.com/posts/preList/486/2274.page GMT
"Have you tried turning it off and back on again?"
]]> https://forums.qrecall.com/posts/preList/456/2150.page https://forums.qrecall.com/posts/preList/456/2150.page GMT That's good to hear.

[quote]QRecall launches *extremely* quickly now. ... (To be fair, I've been running it on an Intel Mac for only a couple of weeks, and most of that was automatic schedules, so I hadn't spent a lot of time actually launching QRecall or opening archives.)[/quote]
The scheduler management logic is much cleaner now; the client application spends almost no time during start up making sure things are in order.

The major speed improvements in opening archives was rolled into 1.0.0(49), so maybe you just hadn't noticed yet. ;)]]> https://forums.qrecall.com/posts/preList/84/354.page https://forums.qrecall.com/posts/preList/84/354.page GMT [code]2010-03-29 03:27:04.027 -0400 Details could not create lock file
2010-03-29 03:27:04.027 -0400 #debug# IO exception
2010-03-29 03:27:04.027 -0400 #debug# API: createFileAtPath:
2010-03-29 03:27:04.027 -0400 Details Path: /Volumes/WD Green (QR)/G5_whole.quanta/.lock
2010-03-29 03:27:04.028 -0400 #debug# OSErr: 22[/code][/quote]
BSD error 22 is "invalid argument"—which doesn't make any sense. This usually indicates that the volume structure is corrupt (which can cause the file system to spit out all kinds of nonsense error codes), or the operating system has simply become "confused." A restart will clear up the latter, and a disk repair will usually fix the former.]]> https://forums.qrecall.com/posts/preList/250/1129.page https://forums.qrecall.com/posts/preList/250/1129.page GMT
Running the shell script for the diagnostic reports gave nearly the same results as the previous one.

That being said, all five items were captured without apparent issue. I'll verify the archive overnight.]]> https://forums.qrecall.com/posts/preList/839/5678.page https://forums.qrecall.com/posts/preList/839/5678.page GMT
If I had to guess, I?d say you had volume structure corruption. You said you checked the drive, but I want to make sure you checked the volume the archive is on (not the volume you were capturing).

The initial error was MacOS error -47 (file busy). This makes no sense on a file that?s on a local drive and is already open. Then, your repair actions fail because the stale .lock file can?t be deleted. The error returned was 22. This is either a dsNoPk5 (no package 5) error or EINVAL (invalid argument). Again, neither of these errors make any sense unless something internal to OS X is botched up.

My suggestions would be (a) restart the system, (b) run disk repair on the volume containing the archive, and (c) make sure you are NOT running any anti-virus, disk optimization, or disk virtualization software that might be interfering with QRecall?s ability to read, write, or delete files on that volume. If your external drive is using ownership and permissions, make sure the files belong to your QRecall user and have read and write access. If they don?t, either fix that or turn ownership and permissions off for that drive.

Then try to repair the archive. Repair should delete the .lock file and verify/restore the integrity of the data in the archive.
]]> https://forums.qrecall.com/posts/preList/484/2267.page https://forums.qrecall.com/posts/preList/484/2267.page GMT https://forums.qrecall.com/posts/preList/22/631.page https://forums.qrecall.com/posts/preList/22/631.page GMT https://forums.qrecall.com/posts/preList/476/2242.page https://forums.qrecall.com/posts/preList/476/2242.page GMT That was easy! Everything is fine now.

Thank you.]]> https://forums.qrecall.com/posts/preList/478/2247.page https://forums.qrecall.com/posts/preList/478/2247.page GMT