You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Wilfredo Sánchez Vega <ws...@wsanchez.net> on 2005/09/22 18:58:20 UTC
Re: Bug in svn on MacOS X 10.4 with ._ files on UFS
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. :-)
Re: Bug in svn on MacOS X 10.4 with ._ files on UFS
Posted by Geoffrey Alan Washburn <ge...@cis.upenn.edu>.
Ryan Schmidt wrote:
>
> On Sep 23, 2005, at 13:38, Geoffrey Alan Washburn wrote:
>
>>> Actually, if Mac users want to store resource forks or extended
>>> attributes in a repository right now, I don't see any reason why
>>> they shouldn't check in the ._ files.
>>
>>
>> Because as the original post that started this thread said, it no
>> longer works in MacOS 10.4.
>
>
> True. I had forgotten about your original post from June [1]. It
> doesn't work anymore as of 10.4, because 10.4 tries to handle the
> situation, and Subversion doesn't realize that a file it thought it was
> handling (the ._ file) has been handled instead by the OS. So you're
> right.
>
>
>>> If people want to use resource forks in Subversion repositories
>>> today, that would be one IMHO reasonable way to do it. Though, as I
>>> mentioned yesterday in another thread, Rez / DeRez may make more
>>> sense, depending maybe on the type of resource.
>>
>>
>> This isn't an option for people that want to store extended attributes.
>
>
> Also true: Rez format is only for resources, not for extended
> attributes. So a solution for storing extended attributes also does not
> exist.
So this brings us back to the point of asking, why are there no plans
to support extended attributes in Subversion? They are a cross-platform
standard, and would make all of these problems go away.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Bug in svn on MacOS X 10.4 with ._ files on UFS
Posted by Geoffrey Alan Washburn <ge...@cis.upenn.edu>.
Ryan Schmidt wrote:
>
> On Sep 23, 2005, at 13:38, Geoffrey Alan Washburn wrote:
>
>>> Actually, if Mac users want to store resource forks or extended
>>> attributes in a repository right now, I don't see any reason why
>>> they shouldn't check in the ._ files.
>>
>>
>> Because as the original post that started this thread said, it no
>> longer works in MacOS 10.4.
>
>
> True. I had forgotten about your original post from June [1]. It
> doesn't work anymore as of 10.4, because 10.4 tries to handle the
> situation, and Subversion doesn't realize that a file it thought it was
> handling (the ._ file) has been handled instead by the OS. So you're
> right.
>
>
>>> If people want to use resource forks in Subversion repositories
>>> today, that would be one IMHO reasonable way to do it. Though, as I
>>> mentioned yesterday in another thread, Rez / DeRez may make more
>>> sense, depending maybe on the type of resource.
>>
>>
>> This isn't an option for people that want to store extended attributes.
>
>
> Also true: Rez format is only for resources, not for extended
> attributes. So a solution for storing extended attributes also does not
> exist.
So this brings us back to the point of asking, why are there no plans
to support extended attributes in Subversion? They are a cross-platform
standard, and would make all of these problems go away.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Bug in svn on MacOS X 10.4 with ._ files on UFS
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Sep 23, 2005, at 13:38, Geoffrey Alan Washburn wrote:
>> Actually, if Mac users want to store resource forks or extended
>> attributes in a repository right now, I don't see any reason why
>> they shouldn't check in the ._ files.
>
> Because as the original post that started this thread said, it no
> longer works in MacOS 10.4.
True. I had forgotten about your original post from June [1]. It
doesn't work anymore as of 10.4, because 10.4 tries to handle the
situation, and Subversion doesn't realize that a file it thought it
was handling (the ._ file) has been handled instead by the OS. So
you're right.
>> If people want to use resource forks in Subversion repositories
>> today, that would be one IMHO reasonable way to do it. Though, as
>> I mentioned yesterday in another thread, Rez / DeRez may make
>> more sense, depending maybe on the type of resource.
>
> This isn't an option for people that want to store extended
> attributes.
Also true: Rez format is only for resources, not for extended
attributes. So a solution for storing extended attributes also does
not exist.
[1] http://svn.haxx.se/users/archive-2005-06/0008.shtml
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Bug in svn on MacOS X 10.4 with ._ files on UFS
Posted by Geoffrey Alan Washburn <ge...@cis.upenn.edu>.
Ryan Schmidt wrote:
> Actually, if Mac users want to store resource forks or extended
> attributes in a repository right now, I don't see any reason why they
> shouldn't check in the ._ files.
Because as the original post that started this thread said, it no
longer works in MacOS 10.4.
> If people want to use resource forks in Subversion repositories today,
> that would be one IMHO reasonable way to do it. Though, as I mentioned
> yesterday in another thread, Rez / DeRez may make more sense, depending
> maybe on the type of resource.
This isn't an option for people that want to store extended attributes.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Bug in svn on MacOS X 10.4 with ._ files on UFS
Posted by Geoffrey Alan Washburn <ge...@cis.upenn.edu>.
Ryan Schmidt wrote:
> Actually, if Mac users want to store resource forks or extended
> attributes in a repository right now, I don't see any reason why they
> shouldn't check in the ._ files.
Because as the original post that started this thread said, it no
longer works in MacOS 10.4.
> If people want to use resource forks in Subversion repositories today,
> that would be one IMHO reasonable way to do it. Though, as I mentioned
> yesterday in another thread, Rez / DeRez may make more sense, depending
> maybe on the type of resource.
This isn't an option for people that want to store extended attributes.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Bug in svn on MacOS X 10.4 with ._ files on UFS
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Sep 22, 2005, at 20:58, Wilfredo Sánchez Vega wrote:
> 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.
Well, as you say, only on non-Mac-native filesystems. So, on HFS, HFS
+ and case-sensitive HFS+, the OS won't create any ._ files for you.
> 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.
Actually, if Mac users want to store resource forks or extended
attributes in a repository right now, I don't see any reason why they
shouldn't check in the ._ files.
For example, on my Mac, I access a working copy that's on a Samba
share on a Linux server, so when my Mac creates resource forks on the
Samba share, it creates ._ files on the Linux server. I could check
these in, and they would work great when access over the Samba share
from a Mac.
If I were storing the working copy on my Mac locally, on my HFS+ hard
drive, then I would have to use /Developer/Tools/SplitForks to split
out the resource fork into a ._ file before checking in, and run /
System/Library/CoreServices/FixupResourceForks to recombine them
after checking out.
If people want to use resource forks in Subversion repositories
today, that would be one IMHO reasonable way to do it. Though, as I
mentioned yesterday in another thread, Rez / DeRez may make more
sense, depending maybe on the type of resource.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org