1. Forum
  2. USENET
  3. comp.sys.mac.system

  • Re: What are these ._something files???

    From zit@ttrtilley@gmail.com to comp.sys.mac.system on Saturday, April 08, 2006 00:32:23
    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 Dave Seaman@dseaman@no.such.host to comp.sys.mac.system on Saturday, April 08, 2006 13:03:23
    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 shamino@shamino@techie.com (David C.) to comp.sys.mac.system on Saturday, April 08, 2006 20:56:35
    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 shamino@shamino@techie.com (David C.) to comp.sys.mac.system on Saturday, April 08, 2006 21:00:53
    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