Subject: Re: [netatalk-admins] NFS/SMB/Appleshare on the same file system

From: "Michael Rothwell" <[email-masked]>
Date: Sun, 13 Jul 1997 10:37:56 -0400

I'm running Samba and Netatalk (and one nfs share) on a Linux 2.0.29
machine, andt works great for me.I've never had a file-locking problem --
just lucky, I guess.

I imagine running Samba+Netatalk is very common. I, and others, I'm sure,
would like to see some sort of integration between Samba and Netatalk. For
instance, Netatalk creates .AppleDouble and .AppleDesktop directories which
are visible from windows machines. If my users copy files or folders out of
one directory to another via windows, it can wreck the .AppleXXXXX
information. Sometimes they just delete  the .AppleDouble directory -- one
shows up on their Win95 desktops (which are stored on the network), for
instance, and they all delete it at their earliest convenience. It would be
nice if Samba could "know" about Netatalk directories and hide them, while
handling them appropriately. Like NT -- the resource forks are never
visible on NT, but always function appropriately. 

Samba's macro features would be very useful on Netatalk. In fact, a unified
Samba/Netatalk server that uses common configuration files would be
extremely useful. 

Of course, use of common lockfiles would be a bonus, also.

I wish I was better with C/C++ --- I could do more than just post my wish
lists.

----------
> From: Kamal Kantawala <[email-masked]>
> To: [email-masked]; [email-masked]
> Subject: [netatalk-admins] NFS/SMB/Appleshare on the same file system
> Date: Sunday, July 13, 1997 1:34 AM
> 
> Dear Samba, Netatalk Administrators,
> 
> I have the following question:
> 
> Is it possible to do the following?
> 
> On a Sun Sparcstation running Solaris 2.5, I want to able to share a
single
> file system volume via NFS, Samba, and Netatalk. Also, I would like to
know
> if there are problems with file locking in the above scenario , i.e. is
it
> possible to stop more than one person from accessing the same file at the
> same time? I would be running Solaris 2.5 on the NFS clients, Win 95/NT
on
> the Samba clients, and MacOS 7.5.x on the Netatalk clients. Most of the
files
> would be Documents, mostly Microsoft Word, Powerpoint, Exel etc. The NFS
client
> usage is not an immediate need.
> 
> If anybody has experience with a similar configuration, your experiences
> and feedback would be very helpful.
> 
> Thanks.
> 
> Kamal Kantawala
> System Administrator,
> MCC, Austin, TX. 
> 
>

---

From: Michael Stone <[email-masked]>
Date: Sun, 13 Jul 1997 14:54:55 -0400

> visible on NT, but always function appropriately. 

There is an (undocumented, AFAIK) config parameter in samba that will 
cause it to hide certain files:

veto files = /.AppleDouble/.AppleDesktop/Network Trash Folder/.appledouble

This is nice for your windows users, because it cuts down on the garbage
in the directories. It would still be nice if netatalk would just allow
you to turn these files off anyway. Think about it; even if the windows
clients don't touch the appledouble stuff, they can still change/move/
delete the originals that the appledoubles refer to. In a mixed environment,
I don't see any point to the appledoubles at all.

-- 
Michael Stone, Sysadmin, ITRI
[email-masked] 
PGP: finger, or email with "Subject: get pgp key"

---

From: Michael Rothwell <[email-masked]>
Date: Sun, 13 Jul 1997 15:43:38 -0400 (EDT)

Well, the .AppleXXXX directories are neccessary, so that the Macs can
'know' about files on the server. They need the resource fork to identify
the file type and creator.

Does that Samba parameter just cause the "hidden" attribute to be set, or
does it actually hide them?

-M

---

From: Julian Elischer <[email-masked]>
Date: Sun, 13 Jul 1997 13:18:58 -0700 (PDT)

> Of course, use of common lockfiles would be a bonus, also.

At whistle communitcations we sell a device that incorporated both
netatalk and samba. I integrated netatalk into FreeBSD for this and 
the present maintainer of SAMBA is on our staff. He is also in charge
of netatalk issues here so you might say that the present maintainer of
SAMBA has daily contact with netatlk. If you look at the
newer releases of SAMBA you will see a feature called "veto file"
What this does is dissallow SAMBA from reporting any hint of a ny
pathname that contains tha names given in that command, to tha SAMBA
users.

our VETO list includes .AppleDouble and other netatlkd related
files. that SAMBA users can never delete their .AppleDouble
directoies because they cannot see them.
The newest patch release of SAMBA (being worked on now) Has
a  NEW version of the veto facility. (I forget it's name)
that has SLIGHTLY differnt semantics. An added feature of the new
code is that if a SAMBA user has an EMPTY directory (as far as they are
concerned, which actually contains a veto'd file that they cannot see.
then a request to delete that directory WILL succeeed, as samba will first
remove the .AppleDouble file, reasoning that there is no longer any reason
for it as the parent directory has no other  entries.

So there is some interaction between SAMBA and NETATALK
already (sponsored by Whsitle communications ( plug plug www.whistle.com))
 We are presently integrating internaltionalisation patches to enable
samba and netatalk to present filenames in other character sets in 
a unified and consistent manner.
thes pathces will be given back as sson as they seem to work..
(The SAMBA patches ARE back by definition as they are being
done by jeremy, the Samba guy..)

We are looking at locking strategies. That will possibly be the 
next action..
we do however need to get some of the netatalk team involved..
(they seem a bit reticent so far)

julian

---

From: Julian Elischer <[email-masked]>
Date: Sun, 13 Jul 1997 13:21:35 -0700 (PDT)

> does it actually hide them?
As I wrote it, I can categorically say that they are TRUELY hidden
from SAMBA users, (except that they will not be able to create
a file with those names (mysteriously they will get an error))

---

From: Michael Stone <[email-masked]>
Date: Sun, 13 Jul 1997 17:12:05 -0400

> the file type and creator.

Hmm. So, how do the macs figure out the file type and creator for
files created by non-macs? If that data can be generated part of 
the time, I don't see why it can't be generated all of the time.
Whether that ability is useful depends on the composition of the
machines on your network, but for people with only a few macs,
it is annoying to have their droppings in all the directories in
the file system. Hiding the appledoubles is aesthetically more
pleasing for non-mac users, but it cause other problems, e.g.,
when one of the non-mac users tries to delete a directory tree
with hidden appledouble directories.

---

From: Richard Wackerbarth <[email-masked]>
Date: Sun, 13 Jul 1997 16:41:05 -0500

>the time, I don't see why it can't be generated all of the time.

It can, it the data is "non-Mac". However, the Mac has no concept
of generating anything in that form.

Because they can assume a "default" when they have no better information,
they can use data generated by another system following some default
name->content mapping.
However, there is nothing to require that the file follows the default
convention. For example, I could create xxx.jpg which was really a
spreadsheet. On the Mac, double-clicking on that document would launch
Excel rather than Photoshop.

---

From: Sak Wathanasin <[email-masked]>
Date: Sun, 13 Jul 1997 23:37:22 +0100

In reply to Michael Stone's message of the 13/07/97 at 17:12 -0400,

> files created by non-macs?

They don't: netatalk uses a heuristic based on any suffices there may be in the
filename (remember that list in the AppleVolumes.system file?) Such a list is,
by definition, incomplete and somewhat arbitrary. For example, text files can
be created by any one of several aapls on the Mac. If you throw away the Finder
info, and you simply use the suffix (.txt, say), there is no way of deducing
which Mac appl actually created the file.

It all depends on whether your Mac users see the netatalk volume as a
convenient way of sharing files with their Unix/Window colleagues or whether
they see it as a true repository for Mac files in which case they'd expect all
info about their files to be kept.

> with hidden appledouble directories.

What problems would that be? If you're going to nuke the directory, what does
it matter what was in it before?

Sak Wathanasin
Network Analysis Limited
178 Wainbody Ave South, Coventry CV3 6BX, UK

Internet: [email-masked]
uucp:     ...!britain.eu.net!nan!sw
Phone: (+44) 1203 419996                    Fax: (+44) 1203 690690

---

From: Michael Stone <[email-masked]>
Date: Sun, 13 Jul 1997 20:03:17 -0400

> info about their files to be kept.

Exactly. It all depends on the application.

> it matter what was in it before?

The unix host won't delete a non-empty directory, even if it looks
empty because the files in it are hidden.

---

From: Scott Schatzer <[email-masked]>
Date: Sun, 13 Jul 1997 23:40:56 -0400 (EDT)

> empty because the files in it are hidden.

But what about rm -fR on Sun systems?  If memory serves, you do not have 
to be SuperUser to use the "R" option, so long as you have write 
permissions to the dir......

--Scott S.

---------------------------------------------------------------------
Scott Schatzer                   | CIESIN
Systems Administrator            | The Consortium for International
[email-masked]        | Earth Science Information Network
Phone: 517-797-2679              | 2250 Pierce Rd.
Fax:   517-797-2622              | University Center, MI  48710
http://www.ciesin.org            |                               
=====================================================================

---

From: Sak Wathanasin <[email-masked]>
Date: Mon, 14 Jul 1997 09:36:58 +0100

> empty because the files in it are hidden.

3 cases to consider:

1) you're doing it from the Unix host in which case you have "rm -rf" or
equivalent
2) you're doing it on a Mac via netatalk in which case the Finder/netatalk does
(1) on your behalf (you did ask to throw away the folder after all, and clicked
"yes" to all the confirmation dialogues)
3) you're doing it on Windows via Samba in which case Samba should do (1) on
your behalf; if it doesn't, it's a bug

(2) certainly works with an arbitary .XXX folder that you can't see on the
desktop; I have no way of checking (3).

Sak Wathanasin
Network Analysis Limited

Internet: [email-masked]