From Newsgroup: comp.sys.mac.system

Dave Seaman wrote:

On 6 Apr 2006 11:16:58 -0700, zit wrote:

tacit wrote:
[...]

Apple is moving away from resource files, but Apple files still have
Type and Creator codes, custom icons, bundle bits, and other Finder
metadata.

minor nit:
custom icons are probably stored as a resource, and not as metadata.
They could be metadata, and perhaps should be, but are they?
Someone would probably gripe if they were abolished :-(

Custom icons may be determined by the file type, which is part of the metadata. All files of a given type share the same icon.

I think tacit was talking about an icon unique to a document.
I'm not sure what the official name of such icons is.
I doubt they are much used. Some malware writers may like them.

--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.mac.system

On 8 Apr 2006 00:32:23 -0700, zit wrote:

Dave Seaman wrote:

On 6 Apr 2006 11:16:58 -0700, zit wrote:

tacit wrote:
[...]

Apple is moving away from resource files, but Apple files still have
Type and Creator codes, custom icons, bundle bits, and other Finder
metadata.

minor nit:
custom icons are probably stored as a resource, and not as metadata.
They could be metadata, and perhaps should be, but are they?
Someone would probably gripe if they were abolished :-(

Custom icons may be determined by the file type, which is part of the
metadata. All files of a given type share the same icon.

I think tacit was talking about an icon unique to a document.
I'm not sure what the official name of such icons is.
I doubt they are much used. Some malware writers may like them.

The original claim was that documents with custom icons would produce ._something files on foreign file systems. This is correct, because the
icon is determined by the metadata and metadata, when it exists, is
stored in the ._something file on foreign file systems. As has been
explained, the ._something files are not only for resource forks.



--
Dave Seaman
U.S. Court of Appeals to review three issues
concerning case of Mumia Abu-Jamal.
<http://www.mumia2000.org/>
--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.mac.system

"John N. Alegre" <info@johnalegre.net> writes:

When I do work from the bash shell(OS X 10.4.5), I often find files in directories that are ._something where there is a file called
something.

What is going on here? Anybody have a clue? Naturally they are
hidden and never show up in finder windows.

Mac OS files are not simple streams of bytes, as they are on other
systems.

A Mac file contains several distinct objects:

- Finder info, which contains things like file type and creator information.

- A data fork (optional, but usually present.) This is a simple stream
of bytes - what is considered the entire file on other operating
systems.

- A resource fork (optional, commonly found, but becoming less common in
recent years.) This is a database-like structure where resources
(identified by type and index codes) are stored. There are literally
hundreds of different types of resources, including bitmaps, fonts,
menus, dialog templates, etc. Back in the days of the 68000
processor, application code was even stored in resources.

- Other named forks. (optional, rare). If an application wants to, it
can create additional forks, structured as the application wants.

The HFS and HFS+ file systems handle all this directly. Other file
systems (including UFS and MS-DOS) do not support more than the data
fork.

When you write a Mac file (which could be saving a document or copying a
file) to a file system that doesn't understand Finder Info and forks,
the data fork is saved with the file's name. The rest of the
information is stored in a second file that is the file's name with "._" prepended to it.

When you mount the volume on a Mac, the "._" files will not show up in
the Finder (although they can be seen from the command line). When you
drag the icon to an HFS or HFS+ volume, the two files will be combined
into a proper multi-forked Mac file.

If you are absolutely certain that your document doesn't use forks and
doesn't need any Finder info (e.g. Microsoft Office documents that have
the proper file-name extension), you can delete the ._ files without
problem. If, however, your document needs its resource fork or Finder
info (e.g. older versions of Claris Works files), then you must not
delete them or the document will break.

-- David
--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.mac.system

tacit <tacitr@aol.com> writes:

All files have Type and Creator codes and Finder metadata. All files.
Even files with no resource fork.

This is not true. If you create files using the UNIX APIs, they will
have no Finder metadata. And copying them to non-mac volumes will not
create a ._ file.

Files without metadata are assigned types based on the filename
extension, and the Finder will use that. But this won't be written to
the file unless you explicitly do something to add it (like making a
change from the icon's "get info" panel.)

If you create the file with Carbon or Cocoa APIs, then you will (or
really should) specify a type and creator, which will create the info.
That file, when copied, will have a ._ file.

-- David
--- Synchronet 3.18b-Win32 NewsLink 1.113