moyman@ECN.PURDUE.EDU (Mike Moya) (04/12/91)
There is a definite problem with System 7.0 and Aufs (Rutgers 2.0 version). I comes by way of trying remove something from an Aufs mounted volume. 7.0 has changed the way things are removed from an AppleShare server somehow. What happens is your Mac hangs in some infinite loop (you can break out of it with the interupt button, >G FINDER). It looks like it creates an invisible folder called "Network Trash Out" on the UNIX side and then hangs... If somebody could get me the new specs I should be able to incorperate a fix. Since I don't know what it's (7.0 appleshare/trash) trying to do I am not real sure how to fix it... Anybody, anybody... Everything else seems to work fine... --moya --Mike Moya --Macintosh Systems and Networking --Engineering Computer Network, Purdue University --moyman@ecn.purdue.edu
rapatel@khnphwzhn.njin.net ( Rakesh Patel) (04/13/91)
You might want to try out Aufs from CAP 6.0, since the folks at
Melbourne have updated Aufs considerably for that release. From
the CAP60.README file:
* AUFS support for AFP 2.0 is (practically) complete (see below).
Has anyone tried the CAP 6.0 Aufs with System 7.0?
Rakesh Patel.djh@cs.mu.oz.au (David Hornsby) (04/16/91)
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 now creates an invisible folder on the AppleShare server called "Network Trash Folder". When you try to delete something by dropping it in the Trash Can, the AppleShare code 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. The restriction is that the file must also be open for writing. I used to believe that no-one would ever even consider trying to byte-range lock a read-only file (although it's legal in AFP). I was wrong! 3. The Mac-end recovery from the lock failure consists of retrying the lock, seemingly ad infinitum (I timed out). I have a gross patch for CAP (any flavour) that lets it work with System 7.0. Hopefully something more elegant will be possible soon ... - David.
tom@wcc.oz.au (Tom Evans) (04/24/91)
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
amanda@visix.com (Amanda Walker) (04/24/91)
In article <1710@wcc.oz.au> tom@wcc.oz.au (Tom Evans) writes:
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.
NFS/Share seems to work well under System 7, although it does require
a working rpc.lockd on the UNIX side, which is a surprisingly rare
beast. If you run bwnfsd (which you should be able to get from Beam
& Whiteside or InterCon), it'll use it for locking instead, as I
understand.
Disclaimer: I'm an NFS/Share tester--contact InterCon for the official
scoop on the state of NFS/Share.
--
Amanda Walker amanda@visix.com
Visix Software Inc. ...!uunet!visix!amanda
--
"Things are more like they are now than they ever were before."
--Dwight D. Eisenhower