Finder stupidity (was NFS locks vs nolocks)

Continuing to threadjack ... we use 'nolocks' as our default for static NFS mounts, and have been running into that infuriating Finder bug since 10.5 -- so while I wish you luck, I would suggest you temper your enthusiasm. :-)

We run into it regularly, anecdotally we hear tell that multiple sessions iteratively result in Finder going stupid, and a reboot is the usual fix.

cheers, Klaus

-- Unintended threadjack

Funnily enough I was playing with nolocks mount options on some of our OSX machines only yesterday. We have long at an issue on these machines (all 10.6.8) where NFS file permissions in the finder do not match those of the terminal, NFS mounts are all to Netapps. That is, a user has access to files/folders in the terminal but the finder says no. The only way we have been able to fix this is either to reboot, or remove the finder cache and reboot, both being quite boring for the end user as it seems to happen quite often.

After some googling around the issue, I have been playing with nolock. Still to early to know if this fixes the issue though.

Dylan

On 11/07/12 7:13 AM, "Greg Ercolano" erco_mlist@seriss.com wrote:

On 07/10/12 12:09, Brian Krusic wrote: > Hi Greg and thanks for the hugely informative post as usual. Took me a >while to read it thoroughly. > > I noticed the same behavior as Nick with AE only when doing local tests.

  AE might try to do something like locking if you're rendering in
  watchfolder mode where it tries to render files that don't exist.
  But hopefully all it's doing is doing file existence checks (which
  is supposedly atomic over NFS), and not trying to do actual locks.  For fun, I ran a test yesterday to see how well locks performed;
  ran two apps that contended for a lock file to manage an incrementing
  number, each app making 10000 lock/unlock operations to change the value.  The locking worked fine on a local drive, and even worked fine
  if the two apps were run over NFS on the same machine.  But when run on separate machines, the locks got out of sync quickly,
  even with fsync() and noac mount options. So I think locking is still
  'a moving target'. In my test case, the NFS server was OSX, and the
  clients were linux.

My only real fear is Vray satellite type renders but I will test that soon.

  I'd suggest asking the vendor if they use file locking, and if they
  do, ask if it's forced to be local files (eg. in /var/tmp or /tmp),
  or if the locking might occur in non-local directories.

To unsubscribe from the list send a blank e-mail to mailto:studiosysadmins-discuss-request@studiosysadmins.com?subject=unsubsc ribe

-- This message was scanned by Fuel's spambox and is believed to be clean.

To unsubscribe from the list send a blank e-mail to mailto:studiosysadmins-discuss-request@studiosysadmins.com?subject=unsubscribe To unsubscribe from the list send a blank e-mail to mailto:studiosysadmins-discuss-request@studiosysadmins.com?subject=unsubscribe