samba - Sep 2006 - Linux Samba to Mac OSX: resource fork lock problems?

I am seeking a better workaround than I currently have for the problem.

Using OS X 10.3.x and 10.4.x (and possibly other versions) as workstations, 
and Gentoo Linux (kernel 2.6.16) with Samba 3.0.22, I have the following 
sequence of events.  The symptom is most prevalent when dealing with multi 
MB files:

1.  Resource fork (._ file) gets locked
2.  File associated with resource fork also gets locked.
3.  File gets unlocked
4.  Resource fork never gets unlocked.

Because the resource fork never gets unlocked, this causes problems with 
migration of data off the Mac to the server and occasionally results in a 
file being deleted unexpectedly.

I can clear the resource fork locks by stopping and restarting appropriate 
server processes.  It's pretty consistent that the Macs request a lock on 
the resource fork and seldom (if ever) release it.  The best hypothesis 
I've heard to date makes this out as a Mac GUI bug, where the 
multi-threaded nature of the GUI creates a race condition between the SMB 
client code and the GUI's refresh, which becomes more prevalent in larger 
files.  I've Googled for these symptoms, and have found reports of this 
problem not only with SMB, but also with NFS.

On the Mac side, we're evaluating "DAVE" (an SMB client program to
replace
OSX's native SMB implementation).  It's meeting with some resistance
from
my Mac users, as the UI is not as convenient as the builtin interface and 
has some problems with locating resource forks, even as it avoids removing 
hours or days worth of productivity.  Our other options are to go to AFP 
via netatalk (which may not resolve the problem), to live with the problem, 
or to purchase a Mac X server and move our Macs off Samba.  None of these 
solutions look really attractive, as they're either going to just push the 
interoperability problem from one platform to another, or have no evidence 
to support it will resolve the problem.

I guess I'm looking for better workarounds. I'm wondering if there's
some
way to, for instance, just veto locks for just ._* files (and what would 
the consequences be for doing that from a protocol standpoint), or a way to 
get some program to test for data fork locks before giving resource fork locks.

Any suggestions?  While similar topics seem to be posted periodically to 
this list and web boards, there doesn't seem to be much of an answer out 
there...

	-Bill
-- 
William Yang
wyang@gcfn.net

On Fri, Sep 22, 2006 at 10:47:49AM -0400, William Yang
wrote:
> I am seeking a better workaround than I currently have for the problem.
> 
> Using OS X 10.3.x and 10.4.x (and possibly other versions) as workstations,
> and Gentoo Linux (kernel 2.6.16) with Samba 3.0.22, I have the following 
> sequence of events.  The symptom is most prevalent when dealing with multi 
> MB files:
> 
> 1.  Resource fork (._ file) gets locked
> 2.  File associated with resource fork also gets locked.
> 3.  File gets unlocked
> 4.  Resource fork never gets unlocked.
> 
> Because the resource fork never gets unlocked, this causes problems with 
> migration of data off the Mac to the server and occasionally results in a 
> file being deleted unexpectedly.
Is this a bug in the Mac client ? Are they forgetting to unlock
their resource forks ? A network sniff would be useful.

Jeremy.

On 22/09/06, William Yang <wyang@gcfn.net> wrote:
> I am seeking a better workaround than I currently have for the problem.
>
> Using OS X 10.3.x and 10.4.x (and possibly other versions) as workstations,
> and Gentoo Linux (kernel 2.6.16) with Samba 3.0.22, I have the following
> sequence of events.  The symptom is most prevalent when dealing with multi
> MB files:
>
> 1.  Resource fork (._ file) gets locked
> 2.  File associated with resource fork also gets locked.
> 3.  File gets unlocked
> 4.  Resource fork never gets unlocked.
>
> Because the resource fork never gets unlocked, this causes problems with
> migration of data off the Mac to the server and occasionally results in a
> file being deleted unexpectedly.
Can you please confirm that this behaviour is present in the most recent
10.4 update?

If it is, could you please get a network trace of this behaviour and
file a bug with Apple? I'm not too familiar with tcpdump syntax, but it
would be best to capture entire packets (-s 0) in both directions (do
you need to "in.pcap port 139" as well?).

See http://developer.apple.com/bugreporter/ for how to file an Apple bug.

thanks,

-- 
James Peach | jorgar@gmail.com