30 Day No-Hassle Money Back Guarantee, all purchases include discounted upgrades and we offer site and forever licenses.
Purchase an upgrade to version 7.
Download A Better Finder Attributes 7.31
for Intel & Apple Silicon Macs, requires macOS 10.15 or later.
Download A Better Finder Attributes 7.27
for Intel & Apple Silicon Macs, requires macOS 10.13 or later.
Download A Better Finder Attributes 7.24
for Intel & Apple Silicon Macs, requires macOS 10.11 or later.
Droplets are mini-applications that store user settings and apply them automatically. This requires the droplet application to be changed after it was built by the developer. Doing this on macOS 13 Ventura or later, however, is detected by the operating system as a potential security risk and macOS will show a dialog with an unhelpful 'This application is damaged' message. You can still run the droplets, but you first need to give them permission to run despite being flagged as 'damaged'. You can do so by right-clicking (or holding the control key and left-clicking, or tapping with two fingers on a track pad) and selecting 'Open' in the context menu.
Full details about the how, what and why are available in this Droplets & Ventura YouTube Video.
Follow the instructions on the installation manual page.
If you experience this problem, there is a simple solution to it:
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:
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.
File dates can be confusing and have non-obvious limits in their range and consistency requirements.
Here's a check list:
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.
The Finder isn't happy with file creation or modification dates that pre-date the 1st of January 1972. More about this below.
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.
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.
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.
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.
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.
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.
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.
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/1677, 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.
Update 2021 on Big Sur: As of Big Sur 11.4, macOS appears to allow file creation and modification dates to be set to any date between 1677 and 1970, as long as both are the same. You can subsequently change the modification date to any value up to (but not including) the 1st of January 1970. As soon as you go beyond that both the creation and modification dates take that later value.
My advice thus remains to avoid pre-1972 dates altogether. A Better Finder Attributes 7 introduced warning dialogs to protect users from trying to use pre-1972 dates. As of version 7.15, this behaviour can be switched off in the Preferences; use this at your own risk if you absolutely need those earlier dates.
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". ;-)
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!
Generally speaking it is not a good idea to work on files that are actively managed by an application like iTunes or Photos. You usually need to export the managed files first, then make changes and finally re-import.
MacWorld has got a great tutorial on how to do just that with A Better Finder Attributes.