Robot.Floss

You can find directions on how to fix the Woot Watchter yourself or you can download it here at RobotFloos.

Instructions:

1. Depending on your operating system, go to the following directory:
   • OS-X: ~/Library/Application Support/Firefox/Profiles//Extensions/{a92aadf8-193f-4a62-8740-5cce81775afc}/chrome/
   • Windows 7/Vista – C:\Users\[Your UserName]\AppData\Roaming\Mozilla\Firefox\Profiles\[Your Profile Name]\extensions\{a92aadf8-193f-4a62-8740-5cce81775afc}\chrome\
   • Windows XP – C:\Documents and Settings\[Your Account Name]\Application Data\Mozilla\Firefox\Profiles\[Your Profile Name]\extensions\{a92aadf8-193f-4a62-8740-5cce81775afc}\chrome\
2. Rename the file “wootwatcher.jar” to “wootwatcher.old” in case you ever want to revert back to it.
3. Now, copy the wootwatcher.jar file from the .ZIP file to the directory
4. Relaunch FireFox and enjoy your w00ting!

Popularity: 4% [?]

All of my Mac Mozy Pro installations have started to freak out. I contacted Mozy support, and it turns out this is a known bug with Moxy Pro 1.6.0. The newest update to 1.6.2 fixes the following problem:

Symptoms:

1.) Mozy Fails to Launch at Start - Under System Preferences -> Account -> Login Items, for all of the users the Mozy Status item is set to launch, but the item is marked as “unknown” rather than “application”. Also Mozy Status does not appear in the Activity Monitor after startup.

2.) Mozy Becomes Hyperactive – About once a minute a “Mozy has finished backing up” window appears. However, no files have been backed up.

The Cure:

1. Force quit Mozy – you may need to do this via the Activity Monitor (Applications -> Utilities -> Activity Monitor)
2. Remove Mozy from your startup items (System Preferences -> Accounts -> Login Items)
3. Uninstall Mozy (drag and drop Mozy from the Applications folder to the trash can and recycle it)
4. Restart computer
5. Install Mozy 1.6.2
6. Restart computer (because you didn’t remove the Mozy preferences file, you will not need to re-enter your account information)

Popularity: 18% [?]

When you build iMovie projects, the program copies all of the imported assets in to a directory specifically for that project. However, if you import a new file with the same name as an existing file, the import will not be updated in the project.

Example:

1. You have a video and add a narrative called “My Narration.mp3″ that is 1:00 long saved to your desktop.
2. Later, you edit the MP3 on the desktop and add 15 seconds to it bringing the length to 1:15.
3. If you delete the narration from the timeline in iMovie and import the new version of the MP3 from your desktop, you’ll end up with the old copy that is 1:00 long, not the 1:15 version.

In other words, the original file you imported isn’t replaced, which makes sense to me as I can imagine scenarios where a user might accidentally change a file. The problem is iMovie never tells you that the assets haven’t been updated.

Here is what should happen:

1. iMovie should compare the two files and determine if they’re different
2. If the files are the same, it should prompt you that no updates have been made to assets
3. If the files are different, it should prompt you to overwrite the original asset or to add the second asset in to the project (and it should automatically rename the asset for you)

Popularity: 8% [?]

Note: As of February 2010, this flaw still exists.

Update (Sept 25th, 2009):

The problem with Mozy having difficulty restoring large files with lengthy revision histories still exists. In the end, Mozy did restore the file for me, but only after the ticket was escalated to level 2 support and finally to level 3 – at which point the tech had to manually restore the file. This took about 7 days.

I needed an Entourage database file restored that had initially been uploaded/backed up to Mozy about 14 months prior. That meant there were thousands of entries in the history of the file that had to be processed. When you request a restore, the machines go back the original file and then move forward through the revision history. If the revision history is long enough, the machines time-out and the restore never completes.

Update (Sept 3rd, 2009 @ 1:51pm):

As you see in the comments, this posting grabbed the attention of the Dan from Mozy.com. The problem isn’t with large files, but rather larges files that have had many changes. For example, a 2.7gb file that changes multiple times a day has a large revision history. A large history can cause a timeout problem when restoring the file. Dan  looked in to the support ticket for me, and here was his response:

“I’ve looked into this more, and it looks like the issue surrounding restoration of long files is that if the file is changing often, then it can take a long time for Mozy to reconstruct the “current” version of the file. We start from the “original” version and then apply each change in sequential order. The restore may timeout before the reconstruction process is complete.

I hadn’t heard of this issue before and am still looking into it. I will forward your comments on to our Support team too.

Thanks,
Dan”

Why no one from Mozy’s technical support took the time to explain this from the start, I’m not sure. But in the end there is a problem, and it is being worked on. I’m not sure by who, but I’m assured it is by top men. Top men.

Original Posting:

I’m a big advocate of Mozy and Mozy Pro. I use the Mozy backup solution at home for 3 machines, and I’ve implemented Mozy Pro across all of the laptops I support at work. I’ve beta tested the product quite a bit for the company, and I even use it as a very last resort backup for my Apple Xserves (this is not the primary backup though, and I do not recommend that).

A few days ago one of my users lost a critical file. I requested the file to be restored, but the restore request  never completed. I called Mozy and spoke to a tech only to learn that it is a known issue – “Mozy has difficulty restoring files over 1gb.”

How much of a problem? Well, they’ve had an engineer working on the problem for over 2 days, and still the issue hasn’t been resolved. I’d love to know more about the back-end situation creating this problem, but for now I’m content to let the level 2 techs work on a solution.

I’m not sure what Mozy is thinking and why they’ve not addressed the problem sooner, but having multiple gigabyte files is not uncommon. Microsoft Entourage databases can easily get the large (even ones that are well maintained and archived), video projects I work on are often much larger than this, and some design files reach this size as well.

So for this issue to exist with Mozy is unacceptable. Until they problem is resolved, I’m going to downgrade my rating of Mozy and Mozy Pro from an A to a D+. The problem is that significant.

Popularity: 36% [?]