3754 Views 7 Replies Latest reply: Dec 2, 2008 7:06 PM by V.J.
Hey, that was funny.
I have other excuses, not the keyboard. Xsan and production workflow is tied to other software that is not certified for new version of the quicktime (and other incompatibilies, and budget....)
Notice that we did not upgrade Xsan to 1.4.2 (we have 1.4.1)
Anyway the Apple recommends that none of the clients have version newer that the server versions.
<Edited by Moderator>
The usual discussion I have with management (I deal with enterprise customers, and they paint themselves into this class of corner with some regularity) is around the trade-offs with running old software in production; what happens if (when?) it all tips over.
There's no good answer.
You're stuck here with a conflict in the business requirements here (the changing Mac OS X configuration appears to be effectively or explicitly uncertified), and that usually means raising a management interrupt and requesting management guidance in breaking a deadlock of management creation.
There's no good technical answer to these management questions.
I see it this way. My job is to maintain project workflow stable and reliable. So I run cvfck until my file system went from 'dirty' to 'clean', and disconnected Leopard Xsan clients.
Then I upgraded Xsan to 1.4.2. Before that I had to upgrade OSX from 10.4.9 to 10.4.11. Before that I had to upgrade some EFI and other software upgrades (that made me nervous!)
Then I upgraded all Tiger clients to xsan 1.4.2
All in all it was smooth and all xsan volumes mounted on the clients computers.
Then on Monday I found out that most of the clients not only are unable to open their FCP project files but it also corrupts the files they tried to open.
It turns that ACL file permission had to be set to 'full' access (it was set before to 'read and write').