Subject: Error -50 copying from OS X

From: Roy Bixler <[email-masked]>
Date: Wed, 19 Dec 2001 12:29:06 -0600

Hi:

I just set up a Netatalk server for about 10 Mac clients, mostly running OS 9 
at this point.  It seems to work just fine for those.  However, when copying 
a directory from an OS X system, it reproducably bombs with an error -50 
message.  For comparison, I booted into OS 9 and the same directory that 
fails with OS X copies OK with OS 9.

The server is running Linux 2.4.16 and netatalk 1.5-pre8.  I have made the 
upgrade to netatalk 1.5-rc1, but it made no difference.  The OS X clients are 
running version 10.1.1.  Are the -50 errors with OS X known problems?  Any 
suggestions?

By the way, for what it's worth, I tried the directory copy with the Fetch 
FTP client and the results were analogous -- it works with OS 9 but fails 
with OS X.

Thanks,

-- 
Roy Bixler <[email-masked]>
The University of Chicago Press
http://www.press.uchicago.edu

---

From: Matthew Keller <[email-masked]>
Date: 19 Dec 2001 13:52:00 -0500

FTP has no intermingling whatsoever w/ Netatalk. They are different
protocols altogether. Perhaps I'm missing something?

-- 

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: Wes Yates <[email-masked]>
Date: Wed, 19 Dec 2001 14:52:56 -0500

>fails with OS X copies OK with OS 9.

You are copying _from_ and OS X system to OS 9? or to Netatalk...? Or 
from Netatalk to OS 9...? or to OS X?

>FTP client and the results were analogous -- it works with OS 9 but fails

 From an OS X system?!? Are you mounting the netatalk volume in OS X? 
or are you somehow mounting the OS X share on the Linux/netatalk 
side...

So OS X "bombs"? I thought that would have been realtively improbable 
under either -- both being Unices and all...

OS X may have a newer or slightly different Appletalk protocol 
stack.. Who knows. Why don't you just do an NFS mount one to the 
other? Perhaps the OS X doesn't like the .AppleDouble!?!

Just thoughts....

-Wes Yates
-- 

-Wes Yates
[email-masked]
wesyates.homeip.net

"Of course, you realize this means war."
-B. Bunny

---

From: Roy Bixler <[email-masked]>
Date: Wed, 19 Dec 2001 16:21:08 -0600

On Wednesday 19 December 2001 01:52 pm, Wes Yates wrote:
> >I just set up a Netatalk server for about 10 Mac clients, mostly running
> > OS 9 at this point.  It seems to work just fine for those.  However, when
> > copying a directory from an OS X system, it reproducably bombs with an
> > error -50 message.  For comparison, I booted into OS 9 and the same
> > directory that fails with OS X copies OK with OS 9.
>

>From OS X to netatalk.

>  Are you mounting the netatalk volume in OS X?

The former.

> under either -- both being Unices and all...

Well, I do consider the aborted copy with the -50 error as a bomb.  No, the 
whole OS X system doesn't crash.

> other?

That's worth a try.

>Perhaps the OS X doesn't like the .AppleDouble!?!

How would I test this?

By the way, it looks like the problem is not so reproducable as I originally 
thought.  The directory which always gave me an error -50 copying from OS X 
to the Netatalk server yesterday copies OK today.

---

From: Rick Zeman <[email-masked]>
Date: Wed, 19 Dec 2001 23:34:24 -0500

> whole OS X system doesn't crash.

I'm getting the same thing copying from 10.1.1 to netatalk RC2; it seems to
gag on nested folders with the error -50.
Seems to happen no matter what DID option I compile with, or with flocks or
not.
This is with Caldera OpenLinux 2.4 and kernel 2.2.20.  Note that this is the
first version of 1.5 that I've tried; I still normally use 1.4b2 (which has
its own problems, but at least I can copy files).

-- 
"So Long, and Thanks For All the Fish."
       --Douglas Adams
          1952-2001

---

From: Rick Zeman <[email-masked]>
Date: Wed, 19 Dec 2001 23:59:46 -0500

> Seems to happen no matter what DID option I compile with, or with flocks or

Actually, I lied: compiling it --with-shadow --with-did=hash --with
tcp-wrappers --enable-redhat  was the winning combination.  Before, I'd user
with-flock-locks and did-last and did=hash.
It'll take someone much smarter than me to figure what's going on....

Good work guys.  Now if I can only get 10.1 to play well with Netware....

---

From: Steve Freitas <[email-masked]>
Date: Wed, 19 Dec 2001 21:08:57 -0800

> Good work guys.  Now if I can only get 10.1 to play well with Netware....

How about --with-shadow --with-did=last --with-tcp-wrappers --enable-redhat?

Also, did-last and did=hash are mutually exclusive options. I'd be
interested to see what happens if you try it without flock, but with
did=last.

It'd be helpful if you could isolate this to a particular configuration
switch.

Steve

---

From: Rick Zeman <[email-masked]>
Date: Thu, 20 Dec 2001 00:33:42 -0500

> Also, did-last and did=hash are mutually exclusive options. I'd be

Absolutely.  I didn't phrase that well.  It was with flocks and two
different compiles with the two did options, all with a make clean in
between.

> interested to see what happens if you try it without flock, but with

I'm pretty sure that I did that, too.  However, since I didn't take good
notes I'm not entirely sure.  Too late to try it tonight.

Anyway, with the above options, I was able to copy 1.6 gigs with nary an
error.

---

From: Steve Freitas <[email-masked]>
Date: Wed, 19 Dec 2001 21:44:38 -0800

> notes I'm not entirely sure.  Too late to try it tonight.

Okay, I hope you can try it soon. It'd be nice to fry that bug.

> Anyway, with the above options, I was able to copy 1.6 gigs with nary an

DID=hash ain't such a hot idea, as it can lead to data loss when inode reuse
occurs. last is considered the most stable, and only runs into inode
problems with large amounts of files, while cnid will hopefully be judged
production ready soon.

Steve

---

From: Rick Zeman <[email-masked]>
Date: Thu, 20 Dec 2001 08:48:28 -0500

>> interested to see what happens if you try it without flock, but with

Error -50s again.  So I HAD done it.  (options were with-shadow,
--with-did=last, with-tcp-wrappers --enable-redhat.

---

From: Rick Zeman <[email-masked]>
Date: Thu, 20 Dec 2001 15:05:04 -0500

On 12/20/01 12:44 AM, "Steve Freitas" <[email-masked]> wrote:

> occurs.

Why is that?

---

From: Steve Freitas <[email-masked]>
Date: Thu, 20 Dec 2001 12:20:10 -0800

>> DID=hash ain't such a hot idea, as it can lead to data loss when inode reuse

To quote Joe Clarke:

"hashdid uses a slightly different algorithm to compute DIDs.  It reserves
the first bit to indicate if this is a file ID, the next seven bits for the
device number, and the remaining 24 for the inode number.  However, since
the inode and dev numbers were hashed, then truncated, this led to duplicate
IDs and data loss."

DID=last can still allow data loss, but you need more files before that can
happen. Note that this data loss occurs when deleting files, and this risk
is minimized when you disable (chmod -R 000) the Network Trash Folder.

Steve

---

From: Roy Bixler <[email-masked]>
Date: Thu, 20 Dec 2001 14:25:54 -0600

> > stack.. Who knows. Why don't you just do an NFS mount one to the

Yes, if I mount the drive with NFS instead of Appletalk and copy to that, the 
directory copy succeeds.