Subject: Re: and yet muddier

From: "Bryn Hughes" <[email-masked]>
Date: Tue, 10 Jul 2001 07:44:43 -0700

Actually, this is because the client creates the Network Trash folder if it doesn't exist.  Since it's created by the client, the first client to connect creates it and it is only writeable by them.

If you change the permissions on the Linux side to allow all users to write to the Network Trash folder and its subfolders, the problem will go away.

Bryn

>>> Thomas Schierle <[email-masked]> 07/10/01 01:00AM >>>
On 01-07-10 02:38 +0200, Chris Herrmann wrote:

> On 01-07-09 15:10 +0200, Thomas Schierle wrote:
>
> Thanks Thomas, will try later today. The problems weren't solved by what I
> tried last night - they only appear when several people are using the
> server, however, over an hour or so. Some other strange behaviour - first
> person on can use network trash, but noone else can.

my guess: multi user network trash needs byte range locking -- a Macintosh
client who logs in looks for the first non-locked byte in the file "trashcan
usage map" and uses the trashcan associated with that byte

> Grr!
> 
> Is anyone able to explain why I should/shouldn't use
> 
> --enable-lastdid

perhaps you should use lastdid? It does provide true unique non-permanent
DIDs which are preferable over non-unique permanent DIDs

> and
> --with-flock-locks

I revisited my server (byte range locking) yesterday opening Quark files
from the server: "file in use" when I try to save an altered file; on "save
as" the file is written to the server but I get a "file in use" error after
the file is written. (QuarkXPress Passport 4.1)

With flock-locks Quark files don't get locked at all for me (Suse 7.0) -- I
was able to open a file that's open in Quark 4.1 a second time using a copy
of Quark 3.32 running at the same client

> The documentation didn't provide many clues as to why you would choose to
> use them. Also, as I'm running it on a Redhat System, should I use:
> 
> --enable-redhat

the redhat option provides you with a startup script adjusted to Red Hats
startup machinery, I don't know why you shouldn't use it

>> Chris, try to compile with --enable-dropkludge, IMO that's
>> an essential if you want to work off your netatalk server with
>> QuarkXPress.

again, try: --enable-dropkludge

>> btw, I don't remember the details anymore -- but I have better luck
>> with byte range locking instead of flock-locks.

my testing as of yesterday did remind me to my problems with file locking:
because I don't work off of the server I simply preferred a (more or less)
working file locking system over saving Quark files ...

good luck,
-Thomas

ps, I'm on vacation from July 10, 2001 to July 19, 2001

-- 
Thomas Schierle, Munich, Germany

PGP key [DSS/DH] 0xA23CDA1D available at various public key servers

---

From: "Chris Herrmann" <[email-masked]>
Date: Wed, 11 Jul 2001 08:55:33 +1000

No, it's not related to Linux permissions on the Network Trash folder -
first thing I checked. They're all logging in as guest users atm, which
would obviate any user/group permission issues - it behave exactly the same
way as when it was running with user perms.

The way to get around user/group problems for folders is to setgid the
directory (g+s <directory>).

It's definitely related to locking, because if a user doesn't use the
network trash for a long time (where a long time is an unspecified number of
minutes/hours/???) then another user can automagically start using it (found
this out last night by accident).

Recompiled with --enable-dropkludge last night - am already
trying --with-lastdid. Using --with-lastdid has meant that I don't see
millions of messages about conflicting DIDs, so it must be doing something
right!

Will let you know how it goes today... fingers crossed.

-----Original Message-----
From: Bryn Hughes [mailto:[email-masked]]
Sent: Wednesday, 11 July 2001 00:45
To: [email-masked]
Subject: Re: and yet muddier

Actually, this is because the client creates the Network Trash folder if it
doesn't exist.  Since it's created by the client, the first client to
connect creates it and it is only writeable by them.

If you change the permissions on the Linux side to allow all users to write
to the Network Trash folder and its subfolders, the problem will go away.

Bryn