Subject: File Copy issues

From: "Brian Curtis" <[email-masked]>
Date: Wed, 2 Jan 2002 10:10:48 -0500

I am trying to copy large folders to my Red Hat linux box running Netatalk.  They are mostly graphic files with in folders and go many folders deep.  What happens is when I copy the folder, which may be a gig in size everything works until it gets to a file that it can not copy, such as a tif.  The problem usually happens with .tiff or .mpeg files and is quote annoying.  If I copy these files one at a time to a different folder then copy them into the folder that I originally tried everything works.

Obviously with about 30Gigabites of data this scheme does not work very well.  The error message I receive always has to do with permissions even though the same user created the folder.

Is there a way to remove permissions from the system and then reaply security aftwards?

---

From: Simon Hobson <[email-masked]>
Date: Thu, 3 Jan 2002 16:42:58 +0000

Brian Curtis wrote:

>I am trying to copy large folders to my Red Hat linux box running
>Netatalk.  They are mostly graphic files with in folders and go many
>folders deep.  What happens is when I copy the folder, which may be a gig
>in size everything works until it gets to a file that it can not copy,
>such as a tif.  The problem usually happens with .tiff or .mpeg files and
>is quote annoying.  If I copy these files one at a time to a different
>folder then copy them into the folder that I originally tried everything
>works.
>
>Obviously with about 30Gigabites of data this scheme does not work very
>well.  The error message I receive always has to do with permissions even
>though the same user created the folder.
>

I had something similar when I first started using netatalk - eventually I
tracked it down to not having rights to create a required directory at the
root level of the share (it was something like the desktop or network trash
- I can't remember the details now). I relaxed permissions on the root of
the share, let the required folders be created, then re-applied security
and everything seems OK now.

Simon

-
Simon Hobson, Technical Services Engineer
Colony Gift Corporation Limited
Lindal in Furness, Ulverston, Cumbria, LA12 0LD
Tel 01229 461100, Fax 01229 461101

Registered in England No. 1499611
Regd. Office : 100 New Bridge Street, London, EC4V 6JA.

---

From: Michael Vanecek <[email-masked]>
Date: Thu, 03 Jan 2002 15:51:42 -0600

I've got a little nagging problem. File transfer, of course. I've 
noticed that the resource file in .AppleDouble for a particular file is 
created with zero permissions altogether, even though permissions are 
set correctly in the main folder. If I go into the .AppleDouble folder 
and set permissions on the particular filename that was giving me 
problems, the file transfer from Mac to Linux occurs without problem. 
Could there be a configuration that I've missed - or could I have 
inadvertantly configured it to be readonly?

Thanks,
Mike

-- 
http://dotfile.net/ - Dedicated to Open Source Software

---

From: Charles Mangin <[email-masked]>
Date: Thu, 10 Jan 2002 08:40:24 -0500

>>folder then copy them into the folder that I originally tried everything

just to reiterate another poster, the problem is not the file itself that you are copying, but in the .AppleDouble or .AppleDesktop folder at the root of the filesystem you are writing to.

there was a fix around here somewhere on the list that described a way to get around the problem, but after having applied it, i promptly forgot where i found it. it involved creating a bunch of empty folders in .AppleDesktop named A...Z and a...z and 0...9 - something to do with creator codes and icons. then set all those read/write via chmod to mode 777

the permissions break down when the files you're copying need custom icons or generic program icons not already on the netatalk system, so it tries to write them to the invisible .AppleDesktop folder for future use (i.e. displaying those files in the finder with proper icons) but the client machine doesn't have write permissions to .AppleDesktop.. thus the error. which happened while writing your TIFF or MPEG files, that have the icon stored in the resource fork, so it misleadingy says you don't have permission to write that file...

at least that's what i recall. hope that helps