Xref: utzoo comp.protocols.appletalk:5731 comp.sys.mac.system:4602
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!spool.mu.edu!munnari.oz.au!mel.dit.csiro.au!latcs1!wcc!tom
From: tom@wcc.oz.au (Tom Evans)
Newsgroups: comp.protocols.appletalk,comp.sys.mac.system
Subject: Re: System 7.0 AppleShare and Aufs problem
Message-ID: <1710@wcc.oz.au>
Date: 24 Apr 91 01:33:37 GMT
References: <9104121604.AA04153@aquarium.ecn.purdue.edu> <7374@munnari.oz.au>
Organization: Webster Computer Corp, Melbourne, Australia
Lines: 36

In article <7374@munnari.oz.au>, djh@cs.mu.oz.au (David Hornsby) writes:
> moyman@ECN.PURDUE.EDU (Mike Moya) writes:
> > There is a definite problem with System 7.0 and Aufs (Rutgers 2.0 version).
> 
> This is also a problem with System 7.0 (at least to beta 4) and CAP 6.0.
> It is due to a couple of things:
> 	
> 	1. AppleShare... tries to byte-range-lock a zero-length file
>	that it has open READ-ONLY. The file is called "Trash Can Usage Map".
> 
> 	2. CAP uses UNIX lockf(2) for byte-range-locking... 

And lockf can't do this. I assume special-case code is needed in CAP
to recognise and "translate" the request into something that can be done
by the Unix file system.

tecot@momenta.com (Ed Tecot), in comp.sys.novell,comp.sys.mac.system writes:
> At Apple, compatibility is very important; it's SOP to fix a third
> party's bug in system software if possible.  

Is it too late for the byte-range-lock-zero-length-read-only behaviour
to be changed (or has it already)?

What concerns me is whether:

	CAP/AUFS	Pacer		Alisa		Novell
	PATHworks	Mt Xinu		UShare		NFS/Share
	Pathway NFS	all the other ones I've forgotten

can handle this now, or if they have to be changed to accommodate
System 7.

========================
Tom Evans  tom@wcc.oz.au ** ADD ".au" MANUALLY (don't trust "reply") **
Webster Computer Corp P/L, 1270 Ferntree Gully Rd Scoresby, Melbourne 3179
Victoria, Australia 61-3-764-1100  FAX ...764-1179  A.C.N. 004 818 455