Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
Re: Dot files
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Dot files

On 6/18/06 at 5:17 AM, Björn Lundin <email@hidden> wrote:

> They come from Finder I think, not Spotlight. Everytime you open a
> folder with Finder, you get the files (or at least one of them) so
> that Finder can remember the size and view it had the last time it
> showed the folder to you.

There's too much misinformation about this stuff out there, and
AppleScripters are technical enough to understand what's *really* going
on, so let's get into it for the sake of the archives.

Here is the real story behind .DS_Store and other ._ files.  Let us
suppose, for the sake of example, that you have a single directory named
"MyFolder", and in it, you have a single file named "MyFile".

First, .DS_Store:

When you open this folder in the Finder, even on an HFS or HFS Plus
disk, and change *anything* about its view - the window location, the
sort, the presentation, the icon size, whatever - then the contents of
the folder now look like this:


The "DS" stands for "Desktop Services", a framework found at
"/System/Library/PrivateFrameworks/DesktopServicesPriv.framework".  It's
private for now, but may go public in later versions of the OS for all
we know.  It seems to handle much of the Finder's work, and is in a
private framework so Apple applications other than the Finder can rely
upon the code.

If you delete these files, you lose *any* Finder-specific information
that may be attached to the folder.  The extent of this is not
documented, but it could be *anything* that's not part of a file's own
metadata.  This could (but does not or will not, necessarily) include
Folder Action attachments, Spotlight metadata, icon views, window views,
window positions, column sizes, icon sizes -- just about anything you
can think of that you set in the Finder that's not part of a file's
actual definition.

This is a risk some people are willing to take, but if you regularly
delete these files and wonder why Finder never remembers your settings,
this is probably why.  The files are harmless, with the possible
exception of other systems that display them when Mac OS X intends that
they should be invisible.

Second, the other ._ files:

Suppose that "MyFolder" is not on an HFS disk, but is instead on an
older MS-DOS or (even better) a UFS disk - one that doesn't support a
lot of file metadata.  Then further support that some program on your
Mac OS X system sets filesystem feature that your disk does not support.
 This could be anything in the HFS Plus set: not *just* a resource fork,
but also file type, creator type, any unsupported date (creation date,
modification date, last accessed date), file label, ACL or other
arbitrary xattr metadata (in Mac OS X 10.4 or later), old-style file
comments, old-style Finder info, and even for some file systems, Unix
permissions (owner ID, group ID, and owner/group/world permissions).

It is not acceptable for a Mac program to set these values and have them
vanish into the ether - it can make programs break rather badly, in
fact.  The OS wants all programs to work as well on all volume formats
as possible.  So, if a program sets *any* piece of file data on a file
system that does not natively support it, the Mac OS X code to implement
that file system stores it in an invisible "companion" file for the
file.  In our example, that now gives us this:


The name for the companion file is the same as the original name
preceded by "._" and, if the file system supports it, set to be
invisible.  This is so that the OS can always find the companion file
based on the original file's name.  The name starts with "." because
many operating systems (most Unix and Linux variants) normally treat
such names as invisible, even if they don't support an explicit
"invisible" flag in metadata.

Note that "._MyFile" is *not* "a resource fork", and *not* "metadata",
but could contain either or both of these.  It contains *anything* that
the Mac OS X file system supports but the volume's own format does not.
You rarely see "._" files on HFS Plus because HFS Plus supports all the
metadata that Apple has defined, now or in the past.  You see a lot of
them on UFS, FAT16, or other old formats that don't support rich
metadata because the OS has to put this stuff *someplace*.


As noted above, this could include a huge variety of data, depending on
the file system.  On MS-DOS disks, you're erasing file permissions like
owner and group, as well as file ownership.  On UFS, you're erasing file
types, creator types, and some access dates.  On almost any non-HFS Plus
file system, you're erasing access control lists, Finder flags, backup
dates, and any fork other than a data fork.  Erasing a resource fork, if
one exists, can delete aliases, custom icons, file binding information
(as in "I want to open this file and only this file in Preview even
though others open in Acrobat"), and any amount of other information.

METADATA OR EXTRA FORKS.  It's your disk, and you can do this if you
want, but there is *no* guarantee, and I mean *absolutely none ever*,
that the file will continue to work as expected in the application that
created it.  It is the *same* as opening it in an application like
Resorcerer or ResEdit and erasing large chunks of metadata and all of
the resources.

Now, admittedly, there are times when you *don't* want resource forks on
files, like JPEG files you upload to a Web server.  On HFS disks, you
can run any number of programs to erase the resource fork to accomplish
this, but most of them recommend operating on backups.  If the file is
on a non-HFS disk, the easy answer is to just *not upload* the companion

Mac OS X does not show you companion files unless you use Terminal, and
sometimes not even then.  (It shows *invisible* files rather easily, but
to Mac OS X, both "MyFile" and "._MyFile" are two parts of the *same*
file, and it doesn't normally return two directory entries for one
file.)  You only see these companion files on non-HFS disks that you
move to other operating systems.

If you want to move the disk back to your Macintosh and have the files
all work properly, I strongly recommend that you leave companion files
alone.  Deleting companion files is corrupting the file.

I fully expect lots of people to go ballistic over this and list tons of
times they've deleted companion files and nothing bad happened.  That's
fine.  There are plenty of wires you can remove in the average
automobile and nothing "bad" will happen in most driving situations.
That doesn't make it smart, supportable, or even necessary.  Leave
companion files alone - they're not bothering anything.  If you have OCD
and feel crawly about those files on your disk, you have issues beyond
what any OS can address.


Matt Deatherage                              <email@hidden>
GCSF, Incorporated                      <>

Q:  What did the 0 say to the 8?
A:  "Hey, nice belt!"

Do not post admin requests to the list. They will be ignored.
Applescript-users mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden

 >Re: Dot files (From: Björn Lundin <email@hidden>)

Visit the Apple Store online or at retail locations.

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2011 Apple Inc. All rights reserved.