[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: MacOS X 10.4 Strangeness with UFS and ._ files

From: Geoffrey A. Washburn <geoffw_at_cis.upenn.edu>
Date: 2005-05-15 18:27:19 CEST

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
  with Subversion.

> > [..] 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
  back.

> > % 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: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sun May 15 18:29:27 2005

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.