Re: [netatalk-admins] odd saving behavior


Subject: Re: [netatalk-admins] odd saving behavior
From: Bill Stewart-Cole (bill@finan.com)
Date: Tue Mar 31 1998 - 12:57:10 EST


At 4:08 PM -0600 3/30/98, John Sutton wrote:

> Sounds like the "persistent file id's" (lack of!) problem. It may be
> relevant for you to detail which applications the users concerned are
> having problems with.
>
> I have problems with Eudora and ClarisWorks which effectively render
> netatalk unusable except for a techie (such as myself) who can understand
> something of what is going on behind the scenes and take appropriate
> corrective action when necessary.
>
> Not wishing to be (too) provocative here, I have to ask: Does anybody use
> netatalk successfully in a "real world" environment?

Is there some other world?

I guess the answer has to be yes. Non-techies use our netatalk-shared
directories all the time, and I even have Samba sharing the same
directories for Windows users. It is second nature for everyone. The only
chronic problem is finessing the added pleasure of having mirror work its
magic on one directory as a bidirectional synch tool. [1]

>And if yes, how do
> they do it? Guidelines please... :-)

Get the permissions stuff right. I can't say what is right for your
environment, but I guarantee that getting permissions wrong will make you
crazy because you will end up with all sorts of mysterious oddities. It's
not something that can be easily 'cookbooked' because everyone has
different security needs and ease-of-use needs. It needs to be thought out
carefully with an eye to your specific situation, and if you don't
understand the interactions between umasks, directory permissions, and how
netatalk maps Unix to AFP permissions, you will be very sad.

[1] This is rather off-topic, but does anyone know of a decent way to
bidirectionally synch directories on 2 Linux machines across a longish
stretch of the Internet where using rsh and its evil relatives is
unacceptable? Mirror is workable with a sufficiently convoluted config,
but it really is not made for the task.



This archive was generated by hypermail 2b28 : Sat Dec 18 1999 - 16:32:05 EST