Migrating drives…any shortcuts? Tools?

[Ron Pestes]

If you have kept all the files related to a project in the same folder you can just copy the folder across to the new drive.

Apple Certified Master Pro FCS 2
Sony EX-3
MacBook Pro

[Shane Ross]

Manually copy the files on the FINDER level. Drag and drop. Then reconnect in each project. And hope that you named each clip…so you don’t have 15 clips all with the UNTITLED name.

Shane

GETTING ORGANIZED WITH FINAL CUT PRO DVD…don’t miss it.
Read my blog, Little Frog in High Def

[Jerry Hofmann]

That would likely work OK, but if you’re going to go thru reconnection, it makes better sense to me to use the Media Manager to make the copies, a new version of the project file, and voila! you’re all connected to copies that have had a sum check done with them during the copy. Not only that, if the names of the media files don’t match the clip names, it won’t matter…

Jerry

Apple Certified Trainer, Producer, Writer, Director Editor, Gun for Hire and other things. I ski. My Blog: https://blogs.creativecow.net/Jerry-Hofmann

Current DVD:
https://store.creativecow.net/p/81/jerry_hofmanns_final_cut_system_setup

8-Core 3.0 Intel Mac Pro, Dual 2 gig G5, AJA Kona SD, AJA Kona 2, Huge Systems Array UL3D, AJA Io HD, 17″ MBP, Matrox MXO2 with MAX – Cinema Displays I have a 22″ that I paid 4k for still working. G4 with Kona SD card, and SCSI card.

[Matt Lyon]

Are you still planning on using your old hard drive? You could copy all your files to the new drive (in a manner that preserves the directory structure). Then unplug your old drive. Change the name of your new array to the EXACT same name as the old drive. Your files should reconnect automatically. So should your render files, if the path names do indeed match.

Matt Lyon
Editor
Toronto

[Al Bergstein]

Thanks for the advice to all of you. You really are saying that the only data pointers of those files is the name of the hard drive? That copying all the files and renaming the hard drive does the job? Sheesh, that would save me time. But I agree with Jerry that checksumming the work is a good thing. Now some developer ought to get to work creating a tool that does just that. hmmm. I think that there are copy tools that do checksums… I’ll have to take a look.

Alf

[David Roth weiss]

[Alf Hanna] “You really are saying that the only data pointers of those files is the name of the hard drive? That copying all the files and renaming the hard drive does the job? “

Some of the time it works… Sometimes not… Manual copying is imperfect at best.

There’s more going on with Media Manager than you might think. Jerry has mentioned check summing, but there’s more than that. The entire FCP database is also checked and rewritten when using Media Manager, making it more efficient and error-free. And, numerous unnecessary render files can also be chucked if you want as well by simply not checking the “include render files” button.

David Roth Weiss
Director/Editor/Colorist
David Weiss Productions, Inc.
Los Angeles
https://www.drwfilms.com

POST-PRODUCTION WITHOUT THE USUAL INSANITY ™

A forum host of Creative COW’s Business & Marketing and Apple Final Cut Pro forums. Formerly host of the Apple Final Cut Basics, Indie Film & Documentary, and Film History & Appreciations forums.

[Matt Lyon]

Hi David, I definitely agree that media manager, when used correctly, can be the most reliable way to move media. But it must be done per project, and is not a one-shot solution like Alf was hoping for.

What also irks me about Media Manager is that it consolidates all your files into one location. So any finder level organization of media is lost (something I do a lot of).

What I really wish Apple would add as a feature is a “preserve relative paths” option in Media Manager. But I suppose this might not work too well if you have media spanning across multiple drives.

As a compromise solution, I reckon you could use the “create offline” option in media manager to create a “cleaned-up” version of your project. Then you could relink to your media after copying it via the finder to the new drive.

I agree that a massive copy of media from one drive to another has the potential to cause problems. I think this is where good organizational habits are important. If you’ve been militant about keeping file names short, and avoiding “problematic” characters and duplicate file names, then things tend to go smoother, in my experience.

Matt Lyon
Editor
Toronto

[Al Bergstein]

Matt said: I think this is where good organizational habits are important. If you’ve been militant about keeping file names short, and avoiding “problematic” characters and duplicate file names, then things tend to go smoother, in my experience.”

I agree with your theory but when you end up using A) AVCHD and it’s “PRIVATE” naming convention, along with B) using an OS that supports long naming conventions (why not use long file names if they are supported? We aren’t going back to DOS anytime soon!) and C) that I am managing only my media and not some collaborative team’s media, then it doesn’t make sense that those issues should be an issue with media management.

I’m willing to be convinced I’m missing something here. Help me understand what you meant…

And yes, this is probably a ‘basics’ question, but I bet ‘basic’ users don’t think about this at all…

Alf

[Matt Lyon]

[Alf Hanna] “I agree with your theory but when you end up using A) AVCHD and it’s “PRIVATE” naming convention, along with B) using an OS that supports long naming conventions (why not use long file names if they are supported? We aren’t going back to DOS anytime soon!) and C) that I am managing only my media and not some collaborative team’s media, then it doesn’t make sense that those issues should be an issue with media management.

I’m willing to be convinced I’m missing something here. Help me understand what you meant…”

Fair enough, Alf. Every situation is unique, so it’s up to each user to figure out what works for them.

AVCHD is outside my experience, so I can’t really comment on that.

But as far as naming conventions goes: It’s true that OS X supports long file names. But I take a “worst case scenario” approach. Maybe some esoteric piece of shareware I need for a certain job relies on some old code that breaks if you feed it really long file names. What if I have to send an EDL to a post house, and their system breaks if the reel names contain more then 8 characters? Playing nice with FCP is only part of the equation, I have to think about the rest of the tools and technology I’m going to interface with.

But just within the realm of FCP, having used it day in and day out since v1.2.5, I feel that keeping things simple just seems to make things more reliable (I guess you could say the same for most software). I have no hard evidence, just an intuitive feel of what works best. I am happy to admit that my approach is uber-paranoid. But part of my approach is keeping file names UNIX friendly (no DOS for me, please)

For instance, when it comes to the meat-grinder that is Media Manager, it seems that the less oddball bits you stuff into it, the more likely you are to end up with something useable coming out the other side.

Having experienced a couple total meltdowns of projects, where every piece of media got disconnected, and the file paths wiped out (in the FCP project), I can say that it is MUCH easier to manually reconnect files when the filenames are short. Additionally, having my clip names in the project match their source media file names EXACTLY was critical. It allowed me do relatively quickly work through the horrible task of manually reconnecting each clip, one at a time.

I hope these late night ramblings make sense and aren’t too academic 🙂 At the end of the day, you gotta decide what way of working fits your needs the best. If you aren’t working in a collaborative environment, I could see how some of my rationales wouldn’t apply, but I hope I’ve explained my thinking clearly at least!

Matt Lyon
Editor
Toronto

[Al Bergstein]

Thanks that makes sense. I haven’t yet had total meltdown but bet it’s ugly. I’ll keep it simple.

Alf