A Better Finder Rename

Handling file pairs in A Better Finder Rename 11

Many photographers working with RAW files often end up with file pairs along the lines of “my RAW image file” + “my JPEG preview image file”, e.g.

image1.cr3image1.jpg
image2.cr3image2.jpg
……

Naturally, when it comes to changing the names of these files, they want to apply the same changes to both file types, e.g.

Current NameNew Name
image1.cr3beach1.cr3
image2.cr3beach2.cr3
..
image1.jpgbeach1.jpg
image2.jpgbeach2.jpg
..

A Better Finder Rename has no built-in support for file pairings, but you can use Filter Actions to make separate “flows” for different file types. As long as you use the same settings for both flows you will end up with the same file names.

Filter actions are special actions that do not change the file name, but decide which files or folders the actions below it in the action table apply to.

You can find out all about filter actions by going to “Help” -> “How to Use Filter Actions” within A Better Finder Rename 11.

  • click on “Show Advanced Sidebar” if it is not yet visible
  • click on the “Add Filter Action” icon on the bottom right of the “Actions” sidebar to add a filter action
  • change the settings to something along these lines:

The filter action above limits all renaming actions below it to only jpg files.

  • add a second filter action to process only your RAW files

The second filter action limits the actions to just “CR3” files.

To recapitulate:

  1. all the actions between the first and the second filter action only apply to JPG files
  2. all actions between the second filter and the end of the action list apply only to CR3 files

In practice, you will probably almost always filter by “First sort by name and sequence number” as this is the way that the files normally come over from your camera, but you also use sorting by EXIF shooting date as long as both your JPEG and RAW image files have the correct meta-data.

I hope that this helps.

The unbearable fragility of modern Mac OS X development

There I’ve done it again: I shipped a broken A Better Finder Rename release despite doubling down on build system verification, code signing requirements validation and gatekeeper acceptance checks, automation, quality assurance measures, etc.

Only in October, I had a similar issue. Luckily that time around it only took a few minutes to become aware of the problem and a few hours to ship a fix so very few users were affected. Right now I don’t know how many users were affected by the “botched” A Better Finder Rename 10.01 release.

This didn’t use to happen. Despite the fact that I did not spend nearly as much time ensuring that everything worked properly with the release management. Nor am I alone in this situation. Lots of big as well as small developers have recently shipped similarly compromised releases.

The situation on the Mac App Store is much, much worse. Nobody other than Apple knows how many Mac App Store customers were affected by the recent MAS certificate fiasco that had the distinction of making it all the way into the pages of Fortune magazine.

The truth is that Mac OS X development has become so very fragile.

The reasons for this are manifold and diverse but boil down to: too much change, too little communication, too much complexity and finally too little change management and quality control at Apple.

The recent Mac App Store (MAS) fiasco that left many (1% of Mac App Store users? 100%? Nobody knows) users unable to use their apps purchased from the Mac App Store was down to Apple’s root certificate expiring. This was a planned event: certificates are used for digitally signing applications and they are only valid for a particular period of time, after which they need to be replaced with new certificates.

When the Mac App Store certificate expired, it was replaced with a new certificate but there were two problems. First, the now expired certificate was still cached by some of Apple’s servers: when Mac OS X opens an application it checks its signature, which in the end is guaranteed by Apple’s root certificate. Since this was no longer valid, Mac OS X refused to launch them and reported them as “broken”, leaving users and developers equally baffled. After far too long, Apple investigated the problem and emptied their caches which made the problem go away.

The second problem which was not solved by updating the caches, was due to Apple also replacing the certificate with a new, higher security version; of course without telling anybody. The new certificate could not be verified with the old version of OpenSSL that was used in the receipt checking code of many shipping apps.

When Apple created the Mac App Store, it provided a “receipt” that each application should check to see whether it has been properly bought on the Mac App Store. This is just a signed file that contains details about what was bought and when. Instead of doing the obvious thing, which would have been to provide developers with an API for checking the validity of the receipt against Apple’s own rules, they just publishing snippets of sample code so that each developer could “roll their own” verification code. Supposedly this was for added security (by not providing a single point of failure), but it seems more likely that they couldn’t be bothered to ship an API just for the Mac App Store.

This decision came back to haunt them, because most developers are not crypto experts and so had to rely on developer contributed code to check their app’s receipts. Once this worked properly, most developers wouldn’t dream of touching the code again.. which is how it came to pass that many, quite possibly a majority, of Mac App Store apps shipped with the same old receipt checking code in 2015 that they originally shipped with in 2010(?). This was fixed by Apple revoking the new style certificate and downgrading it to the old standard.

For once, I had been ahead of the curve and had recently updated all the receipt code in my applications (no small feat) and I have yet to hear from any customers who had problems.

Just before the Mac App Store fiasco, however, many non-MAS had also shipped with broken auto-update functionality.

Apple does not offer any auto-update facility for applications that are not on the Mac App Store, which lead to Andy Matuschak’s “Sparkle” framework becoming the de-facto standard for adding an auto-update features to Mac applications.

Driven by abuse of some HTTP communications in iOS apps, Apple decided that in iOS 9 it would by default opt all developers into using only (more secure) HTTPS connections within their applications. What is good for iOS 9 can’t be bad for Mac OS X 10.11 El Capitan, so Mac applications also got opted into this scheme.

Unfortunately, that broke Sparkle for applications which do not point to HTTPS “app casts” such as mine. I have long resisted installing my own HTTPS certificates because I was worried about messing up the expiry periods, etc.. apparently just the way that Apple did with the Mac App Store certificates.

Most developers will have been unaware of the change since Apple never announced it, but I had happened to see the WWDC conference videos that mentioned this in passing. Unfortunately, nothing “clicked” in my head when I heard this. My applications do not communicate with a server anywhere and I thus thought that this was not something I had to worry about. I had forgotten that Sparkle might use this internally.

Fortunately, I caught this at 6AM when I released A Better Finder Rename 10 final. I was just doing a normally completely redundant check through all the features of the program when I noticed that the new version failed when trying to check for updates. By 8AM, I had identified and fixed the problem so that very few people indeed could have been caught out by it. That was luck though.

The nefarious element here was that applications were opted in automatically and silently. Before 10.11 El Capitan was installed on your Mac, my applications updated just fine. Afterwards, they no longer did. Just because they were on El Capitan. Gee thanks!

Of course, this would not have happened if I hadn’t built A Better Finder Rename 10 with the Mac OS X 10.11 SDK (Software Development Kit) at the last moment.

It is somewhat crazy for a developer to change the SDK that s/he builds a brand-new version of their software against in the middle of the beta phase. Changing the SDK always introduces errors because the entire environment in which the code executes is changed. This may bring out bugs that were already present; things that should never have worked, but worked just because the API happened not to trigger the bug. It also introduces bugs that are just part of the new SDK and that you now have to work around. Changing SDKs makes existing programs fragile.

I’m very conservative when it comes to changing SDKs because I’m well aware of the risks. That’s why I’ve been building my code against older SDKs for the past 15 years. A Better Finder Rename 10 was built against the Mac OS X 10.7 SDK which is forwards-compatible with newer versions of Mac OS X.

The main reason for doing so, is that I wanted to be certain that I didn’t accidentally break A Better Finder Rename on older systems, which brings us to the next problem with Mac OS X development.

Xcode lets you specify a “deployment target”, for instance 10.7, while building with a newer SDK. This is the recommended way of developing on Mac OS X and keeping backwards compatibility. Xcode will, however, happily let you use APIs that are not compatible with your deployment target and thereby ensure that your application will crash on anything other than the latest Mac OS X.

In fact, Xcode encourages you to use the latest features that are not backwards compatible and will rewrite your code for you if you let it, so that it will crash. It will give you “deprecation warnings” for any API usage that is not in the latest SDK and resolving those warnings is likely to break backwards compatibly as well. Of course, you won’t know this until you run it on the old Mac OS X version.

Now which developer can afford to keep testing rigs with 10.7, 10.8, 10.9 and 10.10? Never mind spend the time re-testing every change on multiple platforms for each change?

Thus I happily built with the 10.7 SDK. Apple did not make this easy by not shipping the old SDKs with Xcode, but you could manually install them and they would work just fine.

Imagine my surprise after installing Xcode 7 and finding out that this no longer worked. The only workable solution was to build against the 10.11 SDK, so jumping forwards not one but 4 SDK versions. A bunch of code wouldn’t compile any longer because the libraries were gone. Luckily the receipt checking code was amongst those, so it got modernised just in time to avoid the Mac App Store receipt fiasco.

Nonetheless, now my entire code base had become fragile and largely un-tested between the last beta release and the final shipping product. Nightmare!

On top of that was it still even 10.7 compatible? or indeed 10.10 compatible? Just quickly running it on older systems wouldn’t provide more than a little additional confidence since it’s impossible to go through every code path of a complex product.

After installing virtual machines to test on, I still couldn’t be 100% certain. The solution came in the form of deploymate, a now truly essential developer tool which does what Xcode can’t do: check that API usage is compatible with the deployment target.

I have since spent many weeks trying to ensure that I won’t run into the same problems again by adding (additional) automated verification processes to my build system. My build system now runs the built product through SDK compatibility checking courtesy of deploymate, code signing validation and gatekeeper verifications on each build. I’m still working though deprecation warnings and the like and my code base will soon be bullet proofed at least until the next forced changes arrive.

You’d think that this was a long enough list of problems for one year, but this still does not account for Apple also changing the code signing rules (once again) earlier in the year (in a point update of 10.10 no less). This time it affected how resources and frameworks are signed. So applications that were signed correctly for years, now suddenly became incorrectly signed and Mac OS X would refuse to launch them because they were “broken”.

All this points to the underlying issues with the current spade of fragility of Mac applications: Apple keeps changing the status quo and neither it, nor developers have any chance of keeping up.

Apple’s own applications are full of bugs now. None more so than Xcode, which is both the lynch pin of all Mac OS X, iOS, watchOS and tvOS development and no doubt Apple most fragile app offering. Xcode is in beta at least 6 months a year and never really stabilises in between. Each new version has new “improvements” to code signing, app store uploading, verification code, etc.. and each new version breaks existing code and introduces its very own new bugs and crashes. From one day to the next, you don’t know as a developer whether your code works or not. Existing code that had worked fine on Friday evening, no longer works on Monday morning. Worse, chances are that you are not hunting for your own bugs, but those in your development tools, the operating system or Apple supplied SDKs.

All this is driven by the one-release-a-year schedule that Apple has imposed on itself. This leaves all of Apple’s software in various stages of brokenness. When Apple’s own staff cannot deal with this constantly shifting environment, how are third party developers supposed to?

Case in point: Apple’s own apps are not all iOS 9 compatible yet. Many don’t support the iPad Pro’s new native resolution yet. Some have gained Apple Watch extensions, but most haven’t.

Reliability is a property of a system that is changed slowly and deliberately and where all constitute parts are themselves reliable. The Mac and all other Apple platforms are currently undergoing the worst dip in reliability since Mac OS X was introduced.

Apple is pushing out half-baked annual releases of all its software products, as well as apparently completely unmanaged changes to policies, external rules and cloud services at an ever more frenetic pace.

These could be written off as temporary “growing pains”, but the big question is: Do all these annual updates equate to real progress?

When I switch on my Mac today, I use it for much the same things that I used it for 10 years ago. A lot has changed. Cumulatively Mac OS X 10.11 El Capitan is somewhat better than 10.6 Snow Leopard.. and yet if you discount cosmetic changes and new hardware, nothing much has changed. Certainly nothing much has actually improved.

I can’t help thinking that if we had had 2 or possibly 3 Mac OS X updates instead of 5 over those last 5 years, we’d be in a much better shape now. Apple and developers would have time to provide user benefits and rock solid reliability rather than just endlessly chasing their own tail.

The beauty of the Mac used to be that it just worked. I want to get back to that.

A Better Finder Rename 10 beta auto-update broken on 10.11 El Capitan

We are sorry to report that the auto-update feature on beta releases of A Better Finder Rename 10 is broken on Mac OS X 10.11 El Capitan and you will need to download the update to version 10 (out yesterday) directly from our website.

We  noticed this early at 6AM yesterday while checking the A Better Finder Rename 10.00 release and shipped a fixed version at 9AM (after struggling through work traffic) both GMT+1.

We have over time evolved a build process that guarantees that we only ship high-quality product builds, but we were caught out his time by the rapid pace of change imposed by Apple’s frequent Mac OS X and Xcode updates.

In the past, Apple was quite good about letting developers upgrade their development environments at their own pace, which is important because Mac users do not expect to always have to upgrade their Macs as soon as a new Mac OS X release is dropped. More recently, Apple has transferred a lot of its iOS practises to Mac OS X and have started really pushing developers to adopt features quickly and to get rid of backwards compatibility quickly.

At first this took the form of a gentle prodding, but over time it has become much more aggressive. Essentially they are deliberatley making it hard for developers not to drop support for older OS X versions.

We were caught out in this and still are. We had to install 10.11 on our development machines in order to test on El Capitan properly (the remote debugger has been discontinued for a while now), which lead to an auto-update of Xcode 7.

We had for the past decade built our products using the latest Xcode but using the oldest compatible SDK (in this case 10.7), because this ensures that the builds do not break backwards compatibility for customers on older OS X releases.

We were caught by the fact that Xcode 7 quietly drops the ability to work with older SDKs. Unfortunately building to the 10.11 SDK opts the program into a new rule that the program can only read HTTPS streams for security reasons. This was mentioned at WWDC for iOS applications but OS X hardly gets a mention in those talks. In any event, we did not think that this would affect A Better Finder Rename as we have no server backend, but as it happens, it breaks Sparkle auto-updates, which power our product’s (and 99% of non-Mac App Store applications’) auto-update feature. Note that our auto-updates are securely signed even thought they do not use https.
As a result the auto-update feature works fine as long as you are not on 10.11, but no longer works on 10.11. We only found this out when we shipped the first update since users have started installing 10.11, resulting in a minor but real mess where A Better Finder Rename beta cannot auto-update.
Sorry for the inconvenience.

A Better Finder Rename 10 on the horizon

Hi,

Since the beginning of the year, I have been working flat out on version 10 of A Better Finder Rename and we are nearing the first beta release.

There are a few things that I want to get out there before the first beta ships and those are mostly to do with the Mac App Store and upgrades.

As many of you will be aware of, the Mac App Store is not much loved by Mac OS X software developers, because it is very different from the “traditional” Mac Indie software distribution that many of us feel is superior in very many ways.

Nonetheless most of us “old timers” have made our software available on the Mac App Store due largely to popular demand. Clearly the Mac App Store is better for some customers.

A few years ago, the Mac App Store started to demand that all applications be sandboxed and that was the beginning of the end for many professional productivity applications on the Mac App Store.

Sandboxing itself is a good idea. In a nutshell, it just means that applications cannot access your entire computer, but are restricted to a “safe” container with their own memory and disk space. Access to anything outside that “container” needs to be specifically allowed either by the user or by Apple during their review process.

Many categories of software (i.e. games) work very well in their sandbox, but most professional applications require fairly unfettered file system access, inter-application communication and/or internet access.

Tools such as BBEdit (an awesome text editor), TextExpander (an awesome snippet expander), Panic’s Coda (an awesome web development tool) and many others (many of them awesome) are leaving the Mac App Store because of these limitations.

A Better Finder Rename 9 is in the app store as “Better Rename 9” and we have managed to keep it non-sandboxed by only shipping “fixes” and no major upgrades for years.

By its very nature, a file renaming tool needs unfettered access to the file system. There’s no chance of Apple granting us an “entitlement” to do that during the review process. The reason is that this pretty much defeats the objective of being sandboxed in the first place.

In the idealized sandbox world, it is the user who implicitly grants permission to manipulate files by selecting them in a Open File… dialog or by just drag & dropping them onto the application or its icon. This works fine for our other file utilities such as File Multi Tool/ A Better Finder Attributes, but not for A Better Finder Rename.

The reason for this is simple: on a Unix system such as Mac OS X, the name of a file is not stored in the file itself but in the folder that contains it. Dragging & dropping files only gives access to the file and not to its “parent folder”, so you can change everything except its name.

We would thus either need to ask the you to give Better Rename 9 permission for the parent folder every time you want to rename something, or store that permission somewhere after the first time. Alternatively, we could also ask you to give us permission for the entire disk.

This is not an elegant solution and Apple may or may not accept it. Having played around a bit with other programs that have similar problems, it seems that Apple would most likely allow this kind of “hack” where the program brings up an Open File… dialog and says “Sorry I want to access this file but I can’t, please select it for me!”. Yuck.

We have most of the code necessary to do this and are ready to ship it, but it will undermine the usability of the tool, so we are not certain whether we will continue to support a Mac App Store version beyond version 9.

The next huge problem is how to implement paid upgrades. Nobody wants to pay for upgrades, but upgrade revenue is important for developers and customers alike. The economics of software development are currently bifurcated: you have the traditional developers such as Panic, OmniGroup, BareBones, Red Sweater to name but a few, who diligently plug away at making their products ever more awesome.. then you have the newer App-Store generation authors who create an app, launch it, get a good pay day (or more likely not) then see revenues collapse and move on to the next app product.

Abandonware is okay for some categories of software. Who cares whether Flappy Birds gets updated for iOS 9? Professional software, however, is used for more than mere entertainment. Customers buy into professional software, learn how to use it and expect to be using it for many years to come. They expect the software to supported, for bugs to fixed, for it to work with the latest operating system version and to continously evolve with their own growing needs.

A Better Finder Rename was first published in 1996 on System 7 running on PowerPC-compatible Macs and has constantly evolved since. Version 10 is the most awesome version yet and contains many improvements that would have been just as relevant in 1996 as they are today, as well as many that nobody could have predicted back then. At this point, it has probably broken through 100,000 hours of development and support time. A substantial amount of this time was paid for by upgrade fees.

Paid upgrades have another crucial advantage for long term customers: while fire-and-forget developers optimize for immediate appeal, paid upgrades are almost always targeted squarely at the needs of long term users. It’s a different mind set: The success of a new app depends on how many people buy it now, the success of a paid upgrade depends on how many people are willing to pay for the improvements and the new features.

Paid upgrades are great for professional level software because they allow software developers to spend time addressing the needs of existing customers. That’s why it’s particularly troubling that Apple does not allow for any upgrade pricing on the Mac App Store.. and that’s why developers like me are not very happy about it.

Apple makes the Lion’s part of its revenue on hardware. Software for them is something that makes people buy their hardware, so they can afford to give their software away for free to make you buy more hardware.

Indie software developers are only selling software and don’t get a cut from the hardware sales. In fact if we sell through the Mac App Store, Apple gets a 30% cut of our revenue and that’s after sales tax in most countries (though not most parts of the US). For a 19.99 EUR sale in Germany for instance, a developer only gets 11.76 EUR paid out; the missing 41% goes to Apple and the German VAT office. After the tax office and social security payments here in Luxembourg, there is less than 6 EUR left for me of any one sale of Better Rename 9.

Apple has changed software pricing on mobile devices but also on the Mac quite dramatically. They started by offering iLife (iPhoto, iMovie, etc.) for $19.95, then added iWork (Pages, Numbers,…) again at bargain basement prices. At those price points, just charging you another $19.95 every year is perfectly fine. In the end, all those products are now completely free and Apple makes all its money off the hardware.

Most importantly, Apple has never had to finance the development of those software titles by their actual purchase price. They produced these titles to sell $2,000 MacBooks and iMacs, not for the sake of the $19.95 upgrade pricing. Not surprisingly, none of those applications has seen real effort put into maintaining either backwards compatibility or expanding their feature sets. They are entry level applications because Apple has no real interest in driving their development forwards.

Unfortunately, neither charging the full price for each upgrade or making upgrades free, works for applications such as BBEdit, OmniFocus, Coda or indeed A Better Finder Rename. I don’t want to ask customers to pay another $19.95 for A Better Finder Rename 10, but I can’t afford to make it free either.

Many developers have tried to overcome this problem in a variety of creative but imperfect ways. The ball has been in Apple’s court for years, but it’s very clear that they don’t mean to ever pick it up.

I’m not excluding bringing A Better Finder Rename 10 to the Mac App Store eventually, but in a first phase, A Better Finder Rename 10 will only be available from the publicspace.net website.

Our upgrade terms have always been quite generous: paid upgrades cost 50% of the initial purchase price, are fairly infrequent (every 2-5 years), you can get forever upgrades which cost 100% of the initial purchasing price and if you have only recently bought the product, you get a free upgrade.

For A Better Finder Rename 10 the upgrade terms are as follows:

  •  if you have purchased A Better Finder Rename or Better Rename 9 after the  1st of January 2015, you get a free upgrade
  • if you own a forever upgrade, you get a free upgrade
  • otherwise, you have to purchase a discounted paid upgrade

As you may or may not be aware of, anybody who has purchased Better Rename 9 from the Mac App Store can also run A Better Finder Rename 9 from our website for free. In 99% of all cases, A Better Finder Rename will automatically detect that you have previously bought Better Rename 9 and unlock automatically.

If it does not unlock automatically, all you need to do is to download Better Rename 9 to your machine and run it once. After that you can delete it and A Better Finder Rename will still remember that it was there once.

Once released, A Better Finder Rename 10 should automatically unlock if you have purchased Better Rename 9 from the Mac App Store after the 1st of January 2015. So if you buy Better Rename 9 from the Mac App Store now, or even after A Better Finder Rename 10 is out, you are covered.  If you run into any problems, contact us at support@publicspace.net and we will sort everything out with you.

Likewise, if you own A Better Finder Rename 9 or Better Rename 9 but have bought it before the 1st of January 2015, you can buy the discounted upgrade to version 10 from the upgrade page. You can do so even before A Better Finder Rename 10 comes out.

After version 10 has been out for a while, we will reconsider whether we’ll submit Better Rename 10 to the Mac App Store complete with the crippling “please let me rename this” dialog or leave things as they are.

For us, the important thing is that no matter whether you buy on the Mac App Store or from us directly you will have access to the same versions and will not be penalized in any way.

Unfortunately, Apple does not tell us the identities of anybody who purchases our products on the Mac App Store, so we cannot contact existing customers to let them know of these arrangements.. so if anybody wants to post a comment (developers can’t leave or reply to comments) saying “you can get a free upgrade from publicspace.net!”, you’re more than welcome.

Image Capture Workflow Updated for A Better Finder Rename 9

Back in 2009, we published a couple of blog posts describing how to
use OS X’s Image Capture.app with A Better Finder Rename 8:

The second post linked to an Automator workflow to use with this process, but the release of A Better Finder Rename 9 “broke” this workflow; it works only with A Better Finder Rename 8.

We have updated this workflow for A Better Finder Rename 9, so you no longer have to settle for the default import location. Instead, you may choose your import destination at run-time. Grab a copy of the workflow here:

Announcing Version 9 of A Better Finder Rename

Introducing A Better Finder Rename 9 for Mac

We are thrilled to announce the release of A Better Finder Rename 9. We are excited about this new release and hope that you will enjoy the new version.

Refined Single Window User Interface

As befits a major new release, we have updated and refined the single window user interface introduced in version 8. We are rather pleased with the update and hope you will like as much as we do.

Manual Ordering

This has long been the Number 1 request for A Better Finder Rename and we have finally found a truly intuitive way to implement it.

You can now re-arrange the order of the files in the preview list simply through drag and drop. The sequence numbers, roman numerals or alphabetical sequences will automatically change to take into account the new ordering.

Tag-Based Renaming

Over the years, we kept getting requests for adding this or that type of meta-data. We wanted to find a really great way to integrate all kinds of file meta-data into the product without sacrificing the simplicity and elegance of the interface. The new tag-based renaming feature adds over one hundred tags allowing you to exploit camera, lens, image, color, music & date meta-data in your naming schemes.

Version 9 is but a new beginning

Customers who have been with us since A Better Finder Rename’s humble beginnings in 1996 will know that every new release is only the beginning of a new cycle of iterative refinements. Over the past 16 years, few months have gone by without a point update to A Better Finder Rename and this will of course continue unabated with version 9. We have come a long way in the three and half years between version 8.0 and version 8.95 and we intend to continue developing A Better Finder Rename aggressively.

Free & Discounted Upgrades

A Better Finder Rename 9 is free for all customers who have bought the product after the 1st of January 2011 or who own a forever license.

Upgrades to the version 9 are available at the discounted price of $9.95 (Single User License) from our web store. You can also take the opportunity to upgrade to a family/small business license covering up to 5 individuals or a business license covering up to 100 users.

Better Rename 9 & the Mac App Store

Better Rename 9 is available on the Mac App Store for $19.95 and some of you may prefer using this opportunity to “crossgrade” to the Mac App Store version.

At present Better Rename 9.0 maintains feature parity with A Better Finder Rename 9 and we would like to keep it that way. Note however that on the Mac App Store, everybody plays by Apple’s rules and those rules may at any moment force us to remove features, some of which you may find crucial.

How to use Image Capture to import images to a specific folder and run A Better Finder Rename

A Snow Leopard rewrite of the Image Capture utility brings about many new features, but one has been removed: the ability to specify where to save your photos just before a program is run on those pictures. Image Capture will allow the user to download images to a folder of their choice, or download to the users Pictures folder and then run an external application on those images.

But you want to be able to specify the folder where your images are downloaded, and then use A Better Finder Rename to rename them. Today I put together an Automator action which does this.

Installation instructions:

  1. Download the Automator action here. This will put the file MoveAndRename.tgz in your Downloads folder.

  2. Double-click MoveAndRename.tgz. This will produce a file called “Move and Rename.workflow”

  3. Double-click “Move and Rename.workflow”. This will open the workflow in Automator:

  4. Click File, Save As, name the workflow (the default is “Move and Rename”) and click Save:

  5. The Automator workflow is now saved as an Image Capture plugin.

Usage Instructions:

For more detailed instructions on using Image Capture, check out this tutorial.

  1. Open Image Capture

  2. Under “Import To:” you’ll notice a new option: “Move and Rename.workflow”:

  3. Click “Import” to import the selected images or “Import All” to import the entire camera roll

  4. You are now asked what folder you would like to move the images to. Select the destination folder and click “Continue.” If you don’t want to move the images anywhere, leave “Pictures” selected and just click “Continue”:

  5. Next, A Better Finder Rename is launched. Rename your filesas your normally would.

 

Notes:

  • Automator is unable to save the last folder you used in the “Move Finder Items (Move Images)” step.

  • If you do not select “Replace existing files” in the “Move Finder Items (Move Images)” step, and images files of the same name already exist in the destination folder, Automator will bomb out. This is a limitation of the Automator action.