Subject: RE: Intergrating an MS Windows classroom with an Apple classroom?

From: "David Okeby" <[email-masked]>
Date: Sun, 11 Nov 2001 21:37:30 +0800

Hi,

Just a few things that I have come across when using that kind of
environment... Because of the nature of the metadata that mac's leave
everywhere (the .AppleDouble) folders they sometimes end up cluttering the
shares, and depending on how your Windows computers are set up they will
often see these files lying around.  I have also come across a few problem
of the creator and file type being garbled and the mac's not being able to
open files that the PC's have put there.

However it does work, and for me it works generally really well.

Thanks

David
[email-masked]

-----Original Message-----
From: Chris Bondelid [mailto:[email-masked]]
Sent: Sunday, 11 November 2001 1:05 PM
To: [email-masked]
Subject: RE: Intergrating an MS Windows classroom with an Apple classroom?

I'm running pre6 on RedHat Linux 7.2 no problem.  Mac OS 9.0.4 and 9.1
clients.

-----Original Message-----
From: Shane Pearson [mailto:[email-masked]]
Sent: Saturday, November 10, 2001 4:23 PM
To: Sebastian Rittau
Cc: [email-masked]
Subject: Re: Intergrating an MS Windows classroom with an Apple
classroom?

Thanks Sebastian,

That's good to hear. Do you know if Linux or FreeBSD is
being used for that?

I'm wondering since netatalk originated on BSD?

BFN.

---

From: Jamie Flournoy <[email-masked]>
Date: Sun, 11 Nov 2001 08:58:14 -0800

I haven't tried this but I believe that if you use the HFS filesystem on the
server (which Linux and probably also FreeBSD support natively), there won't
be a need for the additional AppleDouble files, and so when SAMBA clients move
or delete things there won't be any "orphaned" AppleDouble files left over.

---

From: Rob Lineweaver <[email-masked]>
Date: Sun, 11 Nov 2001 21:23:26 -0500

> often see these files lying around.

this problem can be dealt with on the samba side by adding a mondo veto
files line to your smb.conf.  Something like the following is what I use
(all on one line):

veto files = /.AppleDesktop/.AppleDouble/Network Trash
Folder/TheVolumeSettingsFolder/TheFindByContentFolder/Temporary
Items/lost+found/Folder Settings/.finf/.bin/Icon?/Desktop/DesktopFolderDB/

Rob Lineweaver
:)

---

From: Matthew Keller <[email-masked]>
Date: 12 Nov 2001 09:37:51 -0500

Unfortunately (or fortunately, perhaps) HFS does not support
file/folder permissions, and is very VERY inefficient on large disks.
I've done this in small implementations, but it's icky on anything
larger than a trivial file server (and, also, it's not QUITE at slick as
described below, but it'll do the job).

I recommend looking into Samba's "veto files" capabilities. There are 2
directives in that series that will allow making Windows-user's lives
easier when browsing Mac-accessible shares (essentially hiding all the
"apple-specific" stuff).

-- 

Matthew Keller
Enterprise System Analyst
Computing & Technology Services
Information Services Division
State University of NY at Potsdam
Potsdam, NY USA

http://mattwork.potsdam.edu/

---

From: Jamie Flournoy <[email-masked]>
Date: Mon, 12 Nov 2001 07:51:07 -0800

That's unfortunate. In an ideal setup, the filesystem would know about multiple file
extents and extra file metadata, and so when SAMBA moved or deleted something, the
Mac metadata and Resource fork would be moved by the OS as well. I believe this is
what NT and Netware do when sharing files to a Mac.

I guess the next best thing would be for SAMBA to be .AppleDouble file aware, so
that it would move or delete those files itself. Potentially SAMBA could be altered
to read within AppleSingle files, but I have a feeling that would cause performance
problems doing directory listings when trying to give the correct file size for each
fle (it would have to look inside every file and check the size of the data fork).

---

From: "Chris Garrigues" <[email-masked]>
Date: Mon, 12 Nov 2001 10:04:26 -0600

> From:  Jamie Flournoy <[email-masked]>
> Date:  Mon, 12 Nov 2001 07:51:07 -0800
>
> that it would move or delete those files itself. 

that's what the --with-netatalk flag to samba is supposed to do.

Chris

-- 
Chris Garrigues                 http://www.DeepEddy.Com/~cwg/
virCIO                          http://www.virCIO.Com
4314 Avenue C                   
Austin, TX  78751-3709		+1 512 374 0500

  My email address is an experiment in SPAM elimination.  For an
  explanation of what we're doing, see http://www.DeepEddy.Com/tms.html 

    The Greatest tragedy in mankind's entire history may be the
      hijacking of morality by religion.  However valuable -- even
      necessary -- that may have been in enforcing good behavior on
      primitive peoples, their association is now counterproductive.
      Yet at the very moment when they should be decoupled,
      sanctimonious nitwits are calling for a return to morals based
      on superstition.
				--- Arthur C. Clarke

---

From: Matthew Keller <[email-masked]>
Date: 12 Nov 2001 11:13:26 -0500

> fle (it would have to look inside every file and check the size of the data fork).

	There is elementary support within Samba for this, and I am working on
some other Netatalk <-> Samba things. It's not tough, it's just time
consuming. As for your "feeling", yes, that method would be very time
consuming and resource intensive - Effectively "penalizing" Samba for
playing nice with Netatalk. The stuff I'm working on will never do that
(unless someone else makes it so), but will support
moving/copying/deleting Netatalk metacrap (no offense) from Samba. I'm
also working on cooperative locking using Samba's locking scheme, and
also an optional unified configuration interface (eg. when you create a
share, it's a Samba AND Netatalk share, etc.).
-- 

Matthew Keller

---

From: Thomas Kaiser <[email-masked]>
Date: Mon, 12 Nov 2001 17:34:11 +0100

On Mon, 12 Nov 2001 10:04:26 -0600, Chris Garrigues wrote:

> [...]
>> I guess the next best thing would be for SAMBA to be .AppleDouble file aware,
>> so that it would move or delete those files itself.
> 

According to Kevin M. Myer this flag doesn't do a single thing:
<http://www.geocrawler.com/archives/3/5215/2000/12/0/4792504/>
<http://www.geocrawler.com/archives/3/5215/2001/10/350/6762954/>

Regards,

Thomas

---

From: "Chris Garrigues" <[email-masked]>
Date: Mon, 12 Nov 2001 10:45:50 -0600

> From:  Thomas Kaiser <[email-masked]>
> Date:  Mon, 12 Nov 2001 17:34:11 +0100
>

Well, I did say "is supposed to do", so I'm not actually wrong.

Chris

---

From: Thomas Schierle <[email-masked]>
Date: Mon, 12 Nov 2001 21:19:06 +0100

So, wouldn't deploying a streams-aware file system (HFS, HFS+, NTFS, and
others I don't know about) be the natural way to go for a cross platform
share? -- admittedly, I have no idea if Win NT uses streams for Macintosh
metdata.

-Thomas

On 2001-11-12 17:13 +0100, Matthew Keller wrote:

>> so that it would move or delete those files itself. Potentially SAMBA could
>> be altered to read within AppleSingle files, but I have a feeling that would
>> cause performance problems doing directory listings when trying to give the
>> correct file size for each fle (it would have to look inside every file and
>> check the size of the data fork).
> 

-- 
Thomas Schierle, Munich, Germany

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

---

From: Matthew Geier <[email-masked]>
Date: Tue, 13 Nov 2001 09:25:01 +1100

> what NT and Netware do when sharing files to a Mac.

 Their file systems support extended attributes or streams or forks. (I
think the NTFS stream is nearly equivalent to the HFS fork).

 Common Linux/Unix file systems don't have such support. Linux is slowly
gaining extended attribute support, being driven by ACL support in EXT3
and XFS file systems.
 I've been tossing around an idea where NetAtalk would use XFS extended
attributes to store the Mac metadata and not .AppleDouble files. On the
Unix/Samba side if some one renamed the file, it wouldn't matter so much
as the metadata would stay associated, although it would break the CNID
database association.
 Only problem is real resource forks. XFS has a 64k limit on extended
attributes - and a resource fork could be bigger, so resource forks have
to still exist as separate files in the unix file system.

-- 
Matthew Geier			[email-masked]
Arts IT Unit			+61 2 9351 4713
Sydney University

---

From: Steve Freitas <[email-masked]>
Date: Mon, 12 Nov 2001 17:33:03 -0800

> it wouldn't matter so much

Wouldn't the extended attributes be a good place to put the DID info? Then
the whole CNID database thang would go away.

> to still exist as separate files in the unix file system.

Reiser v4 may give you what you want. Of course, you'll have to wait until
30 Sept 2002, then another year before everyone says it's production-ready.
:-( Are there any other options?

Steve

---

From: Matthew Geier <[email-masked]>
Date: Tue, 13 Nov 2001 11:43:07 +1100

> the whole CNID database thang would go away.

 But then you cannot search for a DID with out traversing the entire
file system looking for it.

---

From: Steve Freitas <[email-masked]>
Date: Mon, 12 Nov 2001 18:04:01 -0800

> file system looking for it.

Caching, eh? This way would be sweet because DIDs would be very durable.

Steve