Ben, this isn't entirely correct.
Extended attributes are a well supported feature in Tiger which is
not deprecated at all. Resource forks are a slightly different
thing, but both are stored in ._ files.
First, I think filesystem should be hiding these files now that
the kernel is magically dealing with them. This would mean, however
that attempts to write to a file called ._foo would yield some form
of error (perhaps ENOTSUP). So there is a bit of pollution in the
file namespace, but that's already a problem.
Just FYI, this magic kernel-level "._" file behavior now exists on
*most* filesystems, meaning everything except HFS+, where the magic
is actually supported by the filesystem format. This includes, for
example, NFS.
To clarify the change, in 10.4, the kernel does this magic. The
advantage of that is that the <sys/xattr.h> works uniformly on all
filesystems, the downside being that this magic file stuff is weird
and IMO needs some cleanup. Prior to 10.4, ._ files were handled in
userland, the downside being that only software using CarbonCore (or
CoreFoundation?) could access that data.
The ideal behavior for Subversion would be to map extended
attributes to resource properties and back. Extended attributes and
properties are a good match because both are intended to store small-
buffer-sized chunks of data and behave similarly. Resource forks
remain a bit of a problem because, although I think they can be
accessed by the xattr API, they are not bounded in size and are
accessed using open/read/write functions just like the data fork.
So while, yes, resource forks remain the oddball, I do think it
would be useful and prudent for svn clients to store extended
attributes properly. I also think that WebDAVFS should also be
mapping xattrs to properties and back. There obviously needs to be a
single convention for this. I'd propose that an xattr named "foo" be
mapped to a property named "xattr:foo" and vice versa, the prefix
being useful because not all DAV properties (eg. svn:foo) should be
unmapped to xattrs.
Users should actively avoid storing ._ files in Subversion
repositories directly. The behavior of these files is not the same
on HFS+ as UFS, and it would not be prudent at all for Subversion to
become knowledgeable about them other than to ignore them by default.
-wsv
On Jun 1, 2005, at 8:58 AM, Ben Collins-Sussman wrote:
> On Jun 1, 2005, at 10:42 AM, James Berry wrote:
>
>> Subversion _should_ be made to do this. At that point, the fact
>> that there is a ._file on some file systems should be ignored as
>> an fs implementation detail.
>
> Not gonna happen. Resource forks are deprecated, Apple recommends
> against using them, and so there's no way Subversion is going to
> grow custom code to deal with them. This has been discussed many
> times before. :-)
- application/pkcs7-signature attachment: smime.p7s
Received on Thu Sep 22 21:03:36 2005