Subject: Re: [netatalk-admins] Samba/Unix File Management vs. Resource Forks?

From: Clemens Anhuth <[email-masked]>
Date: Fri, 16 Jul 1999 10:09:07 +0200

a sun wrote:

> samba has a --with-netatalk option that causes samba to treat
> .AppleDouble directories in a special fashion. i suggest that you
> use it.

ah, a compile time option.

i found this in samba-2.0.4/cvs.log:

"netatalk.c contains the meat of the code required to move Macintosh
resource
forks around when Windows users manipulate files created by a mac.
This
allows for greater integration between netatalk and Samba, but is,
of course,
potentially a recipe for disaster.  All the netatalk related code is
insulated
by #ifdefs from the standard build."

makes me go "hm" and <gulp>. :)

and leaves "manipulate files" undefined, but i think this is
important to know in order to judge how far and tight the
integration actually can go.

> in the future, samba and netatalk will cooperate even more.

how far will this go technically?

will making use of windows explorer and the other standard tools
provided with windows 9x/nt (copy, xcopy, etc.) be pure in this
respect and not cause problems?

what about the mentioned case of programs making use of unorthodox
file-management?

i guess the main question is, how bullet-proof will it become with
whatever can be done about this problem?

if you find the time, don't hesitate throwing all the dirty bits and
bytes regarding this at us, i guess some are interested in this.

as far as i can see it comes down to an individual decision per
company, business unit, etc. on wether to integrate samba and
netatalk.

we decided against sharing the same directories via samba and
netatalk for now, because we want to completely rule out problems of
that kind.

(the per default enabled crlf translation of ethershare and suse's
6.1 netatalk package have caused some irritation and consumed quite
some developer time already in our company.)

again, sorry for being resistive and elaborative, i just try to
understand this matter as completely as i can.

thank you for your work and your responsiveness, adrian (and to the
others participating in this thread and on this mailing list of
course).

---

From: a sun <[email-masked]>
Date: Fri, 16 Jul 1999 10:34:43 -0700 (PDT)

the --with-netatalk option will just cause samba to move around
.AppleDouble/blah files along with the blah file. i think there's some
integration in terms of reading configuration files as well, but i'm
not up-to-date in that area. so, it should handle windows copying
without screwing up existing resource forks.

there are number of issues that netatalk and samba need to cooperate
on for things to work transparently:
    1) locking: in the future, netatalk will be able to link against
       samba's locking mechanism. as a result, both samba and netatalk
       should honor each other's locks.

    2) database management. when i'm done with this current snapshot,
       i will be switching netatalk to extensively use a database to
       fix a number of problems. samba (and other programs) need to
       minimally interact with that database so that things don't get
       confused. i will provide command-line utilities to help with
       this as well. note: anyone doing an appleshare solution on a
       unix-style machine basically has to end up doing this. 

    3) file name mapping. i have some code in netatalk, but it allows
       some mappings that cause windows confusion. if someone gives me
       the illegal characters in windows, i'll add an option that
       allows the masking of those characters so that you can't create
       them. 

-a

---

From: "Robert B. Bell" <[email-masked]>
Date: Fri, 16 Jul 1999 13:52:21 -0700

>       allows the masking of those characters so that you can't create

Here is the result from Help on a Windows 95 computer regarding filename
characters.

	A filename can contain up to 255 characters, including spaces. But, it
cannot contain any of the following characters: \ / : * ? " < > |

---

From: Matthew Keller <[email-masked]>
Date: Fri, 16 Jul 1999 17:00:32 -0400

> cannot contain any of the following characters: \ / : * ? " < > |

	Characters with ASCII decimal values less than 32 are also illegal.

-- 

          - Matthew Keller -
       Lead Programmer/Analyst
  Distributed Computing and Telemedia
State University of New York at Potsdam

Web: http://mattwork.potsdam.edu/
PGP: http://mattwork.potsdam.edu/crypto/

---

From: a sun <[email-masked]>
Date: Fri, 16 Jul 1999 16:04:38 -0700 (PDT)

> A filename can contain up to 255 characters, including
   > spaces. But, it cannot contain any of the following characters: \
   > / : * ? " < > |

okay, i'll add a volume-specific options=mswindows that declares such
characters illegal. if you add that with the codepage option, that
should prevent any :xx character generation. it won't solve existing
problems, but it should prevent future problems from occurring.

a quick question: do those pesky files screw up just win9x or do they
cause problems with nt as well?

-a

---

From: Matthew Keller <[email-masked]>
Date: Sun, 18 Jul 1999 13:30:23 -0400

> cause problems with nt as well?

	They screw up NT over a network connection, but NT can use the files if
the were created on the server. Hmmm. That's not very clear, perhaps an
example?

	Mac 1 connects to NT server 1 and create a file called "This / is / a !
Bad ? File". If an NT box tries to access that file over MS networking
on NT server 1, it cannot. If someone sitting at the console of NT
server 1 tries to access it, it is allowed. Does that make more sense?

	Another strange problem: Once Mac 1 creates that file, it cannot delete
it. It can read it, but never delete it. It is necessary to be at NT
server 1's console to delete that file.

	IMHO: Netatalk should prevent the creation of the "bad" filenames
altogether, or perhaps allow for a "translation file", so that Netatalk
admins can map the "bad" characters to a "good" character. For example a
lot of our Mac people are accustomed to creating files with dates such
as "7/7/99 This is a file"- I have a Perl Script on the NT server that
then remaps all of the bad characters to a '.' so the file is now called
"7.7.99 This is a file". This does not appear to work on Netatalk
though, as the file is instantly(?) mangled.

-- 

          - Matthew Keller -
       Lead Programmer/Analyst