buy batch A Better Finder Attributes

Buy From Us for $14.95

30 Day No-Hassle Money Back Guarantee, all purchases include discounted upgrades and we offer site and forever licenses.

Upgrade

Purchase an upgrade to version 6.


How to Uninstall?

Follow the instructions on the installation manual page.

Problems during start up.

A Better Finder Attributes stops working after a while or just after an upgrade. This indicates corrupted or incorrect startup files.

If you experience this problem, there is a simple solution to it:

  • in the Finder select "Go To Folder..." in the "Go" menu
  • type "~/Library/Preferences/" into the text field and click on the "Go" button
  • remove the "net.publicspace.abfa4.plist" file (if it exists)
  • remove the "net.publicspace.abfa5.plist" file (if it exists)
  • remove the "A Better Finder Attributes Pref" file (if it exists)
  • restart A Better Finder Attributes

I'm getting some weird behavior with dates. What's going on?

There's a great deal of confusion about file dates, EXIF dates, timestamps, etc. and much about how they work is un-intuitive to say the least. As a result, using A Better Finder Attributes can be a little confusing at time.

Here's some general pointers that help you make sense of the Mac OS X time/ date jungle.

There are two fundamentally different kinds of dates:

  1. file creation and modification dates
  2. digital picture shooting dates

File creation and modification dates are attributes of the file system. The creation date is the date (and time) that a file was first created on the file system (e.g. your hard disk). Note that this is different from the time and date that the contents of the file were created, e.g.

Say on the 23rd of September 2008, you scan in an old photo that was taken in 1885. The picture file's creation date will be the 23rd of September 2008.

The modification date of a file, is the last time the file was changed. Just opening a file won't change that date. Saving it or changing its name will update the modification date.

Digital Picture Shooting Dates are entirely different and completely separate from the file creation and modification dates. At the moment that your digital camera (or your scanner) creates the new file, it will store this shooting date INSIDE of the new picture file.

A Better Finder Attributes refers to this date as the "shooting date" or "date and time that the digital picture file was shot" or "EXIF" date. Even though it is often convenient to have the file creation date and the picture's shooting date be the same, they are quite separate. Changing one won't change the other. Depending on your camera and the way you import its pictures to Mac they will usually not be the same by default.

Technically, each digital picture format stores this information in a different place. The most common digital picture format is JPEG and digital cameras use a meta-data block called "EXIF information" to store this information inside of the file. The shooting date here corresponds to the "DateTimeOriginal" field of that standard.

Sophisticated digital cameras store unprocessed copies of the images in so called "RAW" formats. Each camera manufacturer has their own mutually incompatible format.

A Better Finder Attributes can read shooting dates from JPEG and the majority of RAW formats.

A Better Finder Attributes can only change the shooting dates of JPEG files with existing EXIF information and select RAW formats.

A Better Finder Attributes' support for changing timestamps in RAW file formats keeps expanding and depends on the version you are using. At the time of writing the current 5.12 versions supports witing to CR2, NEF, ARF, CRW & CIFF format files.

A Better Finder Attributes add shooting dates to JPEG files that do not already have any EXIF information.

My date changes "don't take".

File dates can be confusing and have non-obvious limits in their range and consistency requirements.

Here's a check list:

  • Are you changing the right date?

There's three kinds of dates: the file creation date, the file modification date and the digital picture shooting date (EXIF timestamp). More on this above.

  • Are you using dates before 1972?

The Finder isn't happy with file creation or modification dates that pre-date the 1st of January 1972. More about this below.

  • Are the files not on your local hard disk?

The file creation and modification dates are attributes of the file system. A Better Finder Attributes uses the file system driver of the file system that your file is located on to make the date changes. File system drivers come with different degrees of Mac OS X compatibility.

Changing file dates on volumes (=drives) that are formatted using the standard Mac OS X file system called "HFS+" or "Mac OS X Extended (Journaled), such as your local hard disk, is no problem.

When you start manipulating files on devices formatted using other file systems, e.g. network volumes, memory cards, some third-party hard disks, etc. file dates will only be changed if the file system driver of the device supports this. Moving the files to your local hard disk will resolve such problems.

  • Are you trying to change the shooting date of digital pictures that are not in JPEG format?

A Better Finder Attributes can only change the shooting date of digital picture files that are in JPEG format or in select range of RAW formats, including CR2, NEF, ARF, CRW & CIFF.

  • Are you trying to change the shooting date of JPEG image files that do not come directly from a digital camera?

A Better Finder Attributes can only change shooting dates of JPEG files that already have valid EXIF information. It cannot add EXIF information to JPEG files that do not already have this information. The "Shot on" date of JPEG files that do not contain EXIF information will show as "Unknown" in the file list.

JPEG-format digital picture files that come straight from a digital camera will almost certainly contain valid EXIF information. Some scanners also add such information.

Not all image manipulation programs will preserve existing EXIF information when they save the file. If your digital picture JPEGs seem to "lose" their EXIF information en route, there's a good chance that you are using a tool in your workflow that removes this information when saving the file.

  • Do you have sufficient access privileges for the file?

Mac OS X protects files from un-authorized changes through a permission and authorization scheme. If you are trying to change files that do not "belong" to you or that are important for the operating system (system files, etc), Mac OS X may refuse to execute the changes. You can establish what your access privileges are by selecting the file in the Finder and choosing "Get Info..." from the "File" menu.

  • Are the files "locked"?

Mac OS X protects files from accidental changes by "locking" them. Mac OS X will refuse to execute changes on a locked file. You can establish whether or a file is locked or not by selecting it in the Finder and choosing "Get Info..." from the "File" menu.

  • Is it the file modification date that "doesn't take"?

The file modification date is the date and time that a file was last modified in any way. As such this date changes when you save the file or change its name. This is perfectly normal.

  • Is the file in use by another application?

When a file is in use by another application, it is "locked": neither the contents, nor its creation or modification dates can be changed. Quit the application and try again.

I have trouble with dates before 1972.

A Better Finder Attributes can change your file dates to the distant past if you so desire, but this does not mean that Mac OS X will "accept" those dates as being genuine.

In theory, the creation date of a file is the moment when the file was first saved to disk; this is different from the creation date of the content of the file. So if you have scanned in a photo of Edinburgh in 1912 on the 5th of January 2008, the file's creation date should be the 5th of January 2008, not sometime in 1912.. or at least that's what Mac OS X assumes.

A Better Finder Attributes will happily set the creation date to 1/1/1912, but when the Finder looks at files it performs a few "sanity checks": when it sees that file it "reasons" a bit like this: "in 1912 there were no hard disks, so the file creation is obviously wrong. Let's correct it to X/X/XXXX".

Unfortunately, Apple have never settled on the exact value of X/X/XXXX and when precisely the cutoff date for a "legal" date is. Different versions of Mac OS X will do different sanity checks and apply different corrections and this behavior changes apparently on the whim of the software engineer doing the fix "this time around": dates are set to nonexistent (the file has no creation date!?) or to a "random" date such as 1/1/1972, etc.

The whole situation is further complicated by the fact that different parts of Mac OS X store dates in different ways (for instance in whole milliseconds from 1972, or in positive or negative floating point seconds from 2000, etc.). The offspring of all this is that dates are liable to change in unpredictable ways based on which part of the operating system (Cocoa, Carbon, Unix, Kernel, Classic, etc.) last processed them.

The conclusion is simple: it's not safe to use file dates before the 1st of January 1972 on Mac OS X.

A Better Finder Attributes will set dates before then, but there's no guarantee that the Finder or some other program won't change the date afterwards by "correcting it" or simply miscalculating it.

Something isn't working and I have FruitMenu, WindowShade X, Labels X or anything else using Unsanity's Application Enhancer installed.

With Application Enhancer installed, all bets are off. This is "wicked cool" software specifically designed to undermine OS X's built-in protection features.

Uninstall it and see whether the problem persists.

Blaming other people for your bugs is plain bad manners, so in our defense let us quote George Warner from Apple Developer Technical Support:

Our (Apple's) official policy is that we don't support APE'd systems. Period. The data miner that parses all the crash logs that are sent to us automatically ignores any report that has APE api's in the backtraces or dylb lists.

Likewise If DTS receives a crash incident with API in the backtrace or dylb list we will not investigate it. Our "standard answer" in this case is to inform the developer that we don't support APE and that we'll only be able to help them if they can reproduce the problem without APE installed.

I would suggest that you do the same for your "user X". ;-)

Any other bug at all. Especially right after a new version is released.

Email us immediately! It could be that many other people have the same problem. We can only fix the problems that we know about.

We do test each version carefully before a release, but with so many different factors (OS version, installed products, specific hardware, installers, builds, etc..) to consider, it is always possible that a bug does get into a release.

Unfortunately occasionally a bug affecting all users goes unreported for days and causes no end of frustration for everyone. Simply dropping us a line would allow us to fix the problem immediately.. don't be afraid of getting in touch!