Geoffrey A. Washburn <geoffw <at> cis.upenn.edu> writes:
> > I recently upgraded to MacOS X 10.4 from 10.3 and have been
> > noticing some unusual behavior with respect to ._ files created on
> > a UFS file system. Many of the ._ files programs create are unneeded,
> ._ files as of Mac OS X up to 10.3 Panther contain the resource forks of
> a file and become visible as soon as a file system cannot handle forking
> properly (which is the case for most file systems. Although NTFS can
> handle infinite forks, Windows never actually implemented this).
Yes, I know all of this.
> You could call this "unneeded", but it is in fact Metadata, which once
> deleted is obviously lost.
No, what I said was that many times a ._ file will be created,
but the application never actually uses it.
> > but for whatever reason Illustrator will have a fit if they are
> > missing,
> Therefore, Illustrator puts Metadata in the resource fork that it deems
> essential. This is, as of Mac OS X, discouraged behaviour, but was
> rather common in Mac OS Classic.
No, the data in this case is not essential. The .ai will open
fine under Windows without it, and it is even possible to replace the
._ created with one belonging to any other Illustrator file and not have
any problems. In any event, all of this is irrelevant to the problem
> > [..] Something seems
> > to have changed in 10.4
> In addition to the aforementioned change of the added extended attribute
> fork (something related to, but not directly needed by, Spotlight), 10.4
> also (finally) comes with fully Mac OS X-aware CLI tools. Tools such as
> "cp" and "rm" will now properly respect resource forks, HFS+
> attributes, and other OS X-specific Metadata.
Yes, I know all this too. I even said so in my original message
when I contrasted the behavior of GNU cp with Darwin cp.
> > % rm -rf logo
> ...therefore, this is probably what's changed. The above command will
> also attempt to remove the Metadata (i.e. the ._ files).
No, this should have nothing to do with the problem, because the
._ files are in the repository. The problem is that on a fresh
checkout or update something goes wrong when Subversion is manipulating
the ._ files. Somehow when it says that it has "added" ._whatever, it
really hasn't or the filesystem has done something sneaky behind its
> > % svn update logo
> > A logo
> > A logo/foo-logo-256.png
> > A logo/foo-logo-bw.ai
> > A logo/._foo-logo-color.ai
> > A logo/foo-logo-color.ai
> > A logo/foo-logo-64.png
> > A logo/._foo-logo-bw.ai
> > A logo/foo-logo-128.png
> ...whereas svn probably isn't aware of this.
So are you saying that Subversion is calling out to CLI tools to
manipulate files? I would have thought that it would have only been
using standard library calls or syscalls.
> Just an idea. HTH and regards,
Unfortunately not. Thanks for the explanations, but I really do
understand the issues with ._ files, just not what has changed in the
latest version of Darwin UFS and where this bug needs to be fixed.
-- Geoff Washburn | geoffw_at_cis.upenn.edu | http://www.cis.upenn.edu/~geoffw/ --
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Sun May 15 18:29:27 2005