On May 20, 2006, at 12:10 PM, Nico Kadel-Garcia wrote:
> Ryan Schmidt wrote:
>> On May 20, 2006, at 05:25, Nico Kadel-Garcia wrote:
>>
>>>>> Possible conclusions one can draw from this:
>>>>>
>>>>> * Mac OS X 10.4 is broken.
>>>>> * Resource forks cannot be used with Subversion.
>>>
>>> Or the more correct conclusion:
>>>
>>> * Resource forks are a bad idea, corrupting software and
>>> filesystems willie-nillie.
>>
>> Yes, resource forks are a bad idea today, because of the many and
>> varied unexpected situations one can run into when trying to
>> interoperate with software that is not aware of resource forks
>> because it originated on non-Mac systems (not because they corrupt
>> anything, which they don't).
>
> My experience was that they were never that good or reliable of an  
> idea in the *first* place. Seriously, it forces the OS to double-up  
> on file operations like "copy", "rename", or "move" and creates  
> serious adventures. The benefit was minimal, the hazards quite  
> serious.
I agree that resource forks should be avoided these days, but your  
assertions that they are unreliable or slow down the file system are  
incorrect.
A resource fork is essentially a database attached to a data file.  
They are two separate files that are managed as one by the  
filesystem. Actually, HFS+ supports an arbitrary number of forks on a  
file, not just two. However, I don't think Apple has used more than  
two historically.
The only problem with file forks is that they are unique to HFS and  
HFS+. There isn't a good way to represent them on other filesystems  
and source code that isn't Mac specific doesn't know they exist.  
Resource forks don't "double-up on file operations" as the data  
contained in them would have had to have been copied using some other  
method if resource forks had not been used (e.g. data in a separate  
data file, data added to the main file, etc).
In any event, the original poster should just move to data fork  
resource files. It will solve his issues with subversion and cause  
the least disruption to his code base.
Dave
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sun May 21 18:10:20 2006