Sponsors
Sponsor Products
(last?) nail in the coffin for QuickTime on Windows?
posted by Jeremy Webber  on July 18, 2016, 4:05 p.m. (4 years, 16 days ago)
0 Responses     0 Plus One's     0 Comments  
My favourite Mac NFS problem is that there is a root component on the Mac which reads resource files (those annoying dot underscore" files you cant get rid of).
So if, say, a PDF file is stored on an NFS share to which the clients do not have root squash, and one Mac user opens the file, it opens fine. But when the second Mac user opens the file they get a message saying that the file is corrupted and should be deleted!
What is going on is that even though the first Mac user is only reading the file (its a PDF) the Mac saves a resource fork which is owned by that user. When the second Mac user tries to open the file, the root component finds that the resource fork file exists, but it cannot write as it is nfsnobody. So it seems to assume the file is corrupt!
Im sure there are many other problems. As others have said, Apple clearly do not care about corporate networks or clients. Their OS is only tested for a network of the complexity of a typical home network.
  Jeremy

p.s. the Mac SMB client starts behaving badly if you have more than 10 or so shares mounted. And the Finder gratuitously mounts anything it comes across at an automount point. So using SMB also gives a very poor user experience if you have more than 10 or so automount points (total) in your network.
On 5 May 2016, at 7:18 pm, Ben De Luca <bdeluca@gmail.com> wrote:
Great, This is a good way for me to avoid what I am meant to be doing so lets just use the collective wisdom of the group and get it fixed. or at least be 100% sure of where it is. 

On 5 May 2016 at 11:42, Dan Mons <dmons@cuttingedge.com.au> wrote:

On the road,  so I'll answer in more detail tomorrow.   But remember that access via the BSD subsystem and the Cocoa API layer are different.  Command line tools will act completely differently to GUI tools in OSX as they use an entirely different file cache!  That threw us for ages when we tried to troubleshoot via SSH, and couldn't replicate missing files and directories that artists were reporting in their GUIs.

I'll try and link to the relevant code on Apple's open source site tomorrow (assuming it's still available).

We actually run our OSX render nodes off NFS without problems,  but can't do the same for our artists on the desktop as it causes endless problems. 

-Dan

On 5 May 2016 16:20, "Ben De Luca" <bdeluca@gmail.com> wrote:
So the issue seems to not happen on the cmd line? It seems like the issue is more with the application layer above NFS? 
FSEvents are not being dispatched for remote events? I think thats expected behaviour.
If you make a directory A, with the file in it do you test, but then create a new file/directory  in directory A does update? I think the local change will generate the FSEvent event. 



On 5 May 2016 at 08:16, Dan Mons <dmons@cuttingedge.com.au> wrote:
On 5 May 2016 at 14:50, Ben De Luca <bdeluca@gmail.com> wrote:
> What part of NFS is broken? your statement is like saying computer broken.

Yeah, because I've covered it before on the SSA, and most folks know
the dramas.  But for laughs, here's what I did just now:

Simple test:

* Create lowercase file on Linux/NFS
* Browse to location on Mac/NFS/Finder, open file, read contents, close file
* Rename file on Linux/NFS from lowercase to uppercase
* Browse to location on Mac/NFS/Finder, open file

Depending on your version of OSX, you'll either get an error, or the
file will appear blank.

That's one test you can knock over in seconds.  There's plenty of
others where you get to see funky dancing folders disappear and
reappear depending on various other non-OSX clients on your network,
but they're harder to describe in detail and test trivially.

When they get the trivial test working, I'll cover the test.  FWIW,
that worked fine in OSX 10.4, and broke ever after.  From what I can
tell, it appears that the Cocoa file cache is case insensitive.
Interestingly enough if you do it all via command line in the BSD
subsystem (not Cocoa), you don't have the problem.  The trouble starts
when you call something from the command line that fires up a Cocoa
app (basically anything you can call by association with the "open"
command).

-Dan
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

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

-- 
Jeremy Webber
Senior Systems Engineer
Animal Logic Pty Ltd
Tel: +61 2 8310 3577
Main: +61 2 9383 4800
Fax: +61 2 9383 4801



Thread Tags:
  discuss-at-studiosysadmins