._ files

[Richard Gaskin]

Robert Brenstein wrote:
>> Robert Brenstein wrote:
>>> For those wondering about those ._ files, here is the explanation 
>>> from the "guilty" party, Apple itself:
>>>
>>> http://docs.info.apple.com/article.html?artnum=106510
>>>
>>> For most files, these ._ are actually empty and in case of Rev stacks 
>>> safely ditched.
>>
>> So in all cases where the file has no resource fork (many Classic 
>> file, most OS X files, and just about all Rev stacks, MP3s, MPEGs, and 
>> more) it's merely a waste of time and space.
>>
>> That Apple provides no option for the user to be able to decide 
>> whether this happens is an unfortunate design decision.
>>
>> That Apple does this for files that have no resource fork is a bug.
>>
>> That is, it would be a bug but another poster here already pointed out 
>> that no software vendor in the world 'cept RunRev ever ships anything 
>> with known bugs. ;)
> 
> Well, no, it is not exactly a bug in the way you present it. I 
> simplified above (distorted the truth if you wish) saying that files are 
> empty: they contain at least a single line with Finder info, like file 
> type and creator, which is good enough reason to create that file even 
> for files with no resource fork.

But many OS X apps (even some from Apple?) don't set the Finder info, 
relying on OS X's preference to determine type from the file type 
extension in the name.

But okay, it's not a bug per se.  My main point there was having fun 
with the notion that no vendor except Rev has ever shipped any software 
with known bugs. ;)  Of course there are enough examples that we needn't 
stretch to find more.

I still feel it would be useful to allow users to be in control of these 
additional files.  It makes it cumbersome to use any non-Apple Flash 
drive, work with multi-platform networks, etc.  Not allowing that 
control just makes Apple look bad, lending credence to the old lightbulb 
joke:
<http://lists.runrev.com/pipermail/use-revolution/2004-January/028106.html>

--
  Richard Gaskin
  Managing Editor, revJournal
  _______________________________________________________
  Rev tips, tutorials and more: http://www.revJournal.com