Subject: RE: Hidden Files Not Being Copied

From: "Vaughn, George" <[email-masked]>
Date: Thu, 18 Jan 2001 10:47:19 -0800

Macs don't create files without resource forks. If a file exists on a MacOS
filesystem (FS), it has a resource fork. If a file is copied to a MacOS FS
without a resource fork, one is created as soon as MacOS looks in the
directory (this is why MacOS takes a while for DOS-formatted disk contents
to appear, it's creating resource forks for the contents of the viewed
directory).

Netatalk appears to translate the resource forks to the Linux attributes
(probably via the .AppleDouble file) and vice versa, but the resource forks
*definitely* exist on the MacOS FS, and that *is* where the permissions,
date created, date modified, etc. info exists, as well as the visibility
flag and custom icons (years of resource fork editing via resEdit experience
talking here).

Macs can create files with anything in the filename except ":" or "/" on any
local system, as far as I know. The MacOS hasn't had a problem with leading
periods since at least 1996. The problem that's being seen with the ":e2"
replacing the "." is something occuring in Netatalk (at a guess, to prevent
the files from becoming invisible).

There's my $.02

George Vaughn
[email-masked]

-----Original Message-----
From: Ray Zimmerman [mailto:[email-masked]]
Sent: Thursday, January 18, 2001 10:14 AM
To: Bill Moran
Cc: Netatalk List
Subject: Re: Hidden Files Not Being Copied

At 12:58 PM -0500 1/18/01, Bill Moran wrote:
>  > Each file has a set of attributes stored with it indicating whether
>>  it is visible, the file type, creator app, whether it is locked, etc.
>
>Is this part of the resource fork?

I'm not 100% sure where it is stored, but I think it's part of the 
file system definition (wherever file create and mod dates are 
stored). It's definitely not in the resource fork though, because 
files with no resource fork have this info.

>If so, how is this resource fork represented through Netatalk? The
>invisible attribute could be stored there as well.

I believe it is. IIRC the AppleDouble format stores the resource fork 
as well as these extra file attributes not included in other files 
systems. If you create files on the Mac and copy them to netatalk all 
of these attributes stay intact. If the file starts with a . that 
gets encoded when copied to a netatalk volume.

>Another thought: Why are dotfiles ignored to begin with? Why not just
>hide the .AppleDouble and .AppleDesktop files but show other dotfiles?

The only way to get a dotfile is to create it on the *nix side I 
believe, in which case it is intended to be invisible. So I still 
think it should be made available to the Mac side, but as a file with 
the invisible bit set.

Next best would be just to make them available as visible files.

	Ray

---

From: Ray Zimmerman <[email-masked]>
Date: Thu, 18 Jan 2001 14:14:37 -0500

Sorry, I'm going to have to respectfully disagree with you on a few 
things here George ...

Not all Mac files have resource forks. I can send you one without if 
you like and you can verify it by trying to open it in ResEdit and 
having it tell you that it doesn't have a resource fork and would you 
like to create one.

Again, I believe the Finder attributes (dates, invisible flag, etc) 
are actually part of the HFS and HFS+ definitions.

The DOS-formatted disk phenomenon you mention has to do with creating 
the Finder.dat files which contain these attributes, but resource 
forks are not created.

Also, a '/' is legal in a Mac file name. I think it's only the ':' 
(the MacOS directory separator) that's illegal.

	Ray

---

From: David R Bosso <[email-masked]>
Date: Thu, 18 Jan 2001 11:19:21 -0800

--On Thursday, January 18, 2001 10:47 AM -0800 "Vaughn, George" 
<[email-masked]> wrote:

> Macs don't create files without resource forks. If a file exists on a
> MacOS filesystem (FS), it has a resource fork. If a file is copied to a
> MacOS FS without a resource fork, one is created as soon as MacOS looks
> in the directory (this is why MacOS takes a while for DOS-formatted disk
> contents to appear, it's creating resource forks for the contents of the
> viewed directory).

Woah, I think you're confusing resource forks with Finder information. 
Resource forks are _not_ ubiquitous.  Maybe you've never tried opening a 
file with Resedit that does not have a resouce fork and recieved the 
following dialog:

"The file 'filename' has no resource fork.  Opening it will add one. Do you 
wish to open it?

-David