RoHS CompliantAll Small Tree cards, switches and storage products are RoHS compliant!

Tips for Happy Shared Storage Workflows

June 24, 2013 by Steve Modica

1.  When you have lots of media coming in from various cameras to your shared storage, make sure you are ingesting that media using appropriate software.

We have seen a few cases where people are dragging files in from the camera using the Finder, rather than the camera vendors import software.
When you do this, the media can sometimes have the “User Immutable” flag set.  This flag prevents users from accidentally deleting files, even if they have appropriate permissions.  You can see this flag via Right Click->get info.  It’s the “Locked” flag.

While this makes sense if the media is on the camera (where they expect you to do all deleting with the camera software interface), it does not make sense on your storage.  However the flag is persistent and will also be set on any copies you make and any copies you make of those copies.  It will also prevent the original files from being deleted when you “move” a large batch of material from one volume to another!

Obviously this will waste a lot of space and be very frustrating down the line when you have thousands of media files you can’t delete.  You’ll also find that unsetting the Lock bit via “get info” is way to cumbersome for 10,000 files.

One simple answer is the command line. Apple has a command (as does FreeBSD) called “chflags”.  If you can handle using the “cd” command (Change Directory) to navigate to where all your Locked file are, you can run:

chflags -R nouchg *

This will iterate through all the directories and files (starting from whatever directory you’re in) and clean off all the “Locked” bits.

2.  Edit project files from your local machine, rather than shared storage.

There are a number of reasons to do this, and as time goes on, I seem to find more.

First, it’s just safer.  Not all apps lock project files. So it’s possible that if you have enough editors all sharing the same space and everyone is very busy and the environment is hectic, someone could come along and open a project you already have open.  If they “save” their copy after you save yours, your changes will be lost.  It would be no different if it was a Word Document or Excel Spreadsheet.  When multiple people save the same file, the last guy to save wipes out the first guy.  (This is not a problem for shared media like clips and audio since those files are not being written, just pulled into projects).

Second, apps like Avid and FCP 7 all have foibles with saving to remote storage. Avid doesn’t like to save “project settings” over Samba or AFP (although NFS and “Dave” from Thursby work fine). FCP seems to mess up its extended attributes when it saves, leading to “unknown file” errors and other strange behavior.  (When this happens, you can easily fix it.  See Small Tree Knowledge Base solution here: http://www.small-tree.com/kb_results.asp?ID=43).

Lastly, you may have different versions of apps on different machines.  I recently had a customer that was using FCP 7.0 and attempting to open files written by FCP 7.0.3.  The older app was unhappy with the newer format files and it created some strange error messages. While this would have been a problem no matter how the files were accessed (locally or over the network), the network share made it more confusing since it was not clear that the files came from another system.  Had the user received the projects on a stick or via email, the incompatibility would have been much more obvious from the start.

If you have any questions regarding shared storage and improving your workflow, do not hesitate to contact me at modica@small-tree.com.


No Comments

No comments yet.

RSS feed for comments on this post.

Sorry, the comment form is closed at this time.