At some point Java 7 apparently introduced the ability to create hard links via the createLink function. Is there anything that would prevent this from being used when an album includes originals, so that duplicate files aren't created on disk? Thanks.

That depends. How is this different from choosing Link rather than *Copy*? What happens if the original is deleted, or moved to an external, removable drive, or to a networked drive? How do typical backup programs (e.g., robocopy, Carbonite) handle it? What happens if you try to copy the entire project to another platform?

There are reasons why we typically tell people to choose Copy.

Does anyone have any objections to the use of hard links instead of copies whenever possible?
Seen the link to Stackoverflow you posted, have you seen this one, https://superuser.com/questions/302051/how-do-you-create-a-working-hard-link-in-osx
That is on OS X, at least, they can get broken by opening and saving in an application. For OS X I'd much prefer the much smarter alias be supported.

So editing the "original" sometimes have you end up with two files again. That isn't that bad, is it?

It's not just that the image will have been modified. It's that the HTML won't know about the change, so in most "traditional" skins (which use height and width attributes on the <img> tag), you'll get a stretched or squeezed image.


Yes, tough to say without testing a bunch of them.

The potential for problems is a fairly "fringe-y" case - I suspect most users would never run into it. It wouldn't cause a problem if the user did something else to the original, like changing the gamma - it's only the "new aspect ratio" situation that's dangerous. And I suspect most users are sticking to linking to scaled images, anyway, which would be untouched by this.

It might be enough to warn users that if they link to originals and change the originals after making the album, they should do a quick Make Album before uploading. Even with a large album, it should run very quickly, since there's no new processing being done - at worst, a few new slide HTML files.

You can guess what I'm going to say next, right? I'd like this to be a settings option somewhere, rather than being hard-coded. You could bury it deep, like Tools, Preferences, Album - it doesn't need to be "front and center" in the project settings.

In the answers section the comment 'The reason for this behavior is rather straightforward, and it relates to how files are saved in most Mac OS X applications: Atomically. What happens is that a copy of the file is written to a temporary staging area, and then moved to replace the original file. *This, quite naturally, breaks hard links*'

To me, that indicates the hard link would point to a deleted file and the edited version would no longer be part of the album - so, for example a slide page would have no image. This is not much of a problem as long as the hard links are only ever used in the album directory, not the project directory.

This seems something that would benefit from an extend trial period, so users can try different file types in a project and see how things work.

Yes, no, maybe - who knows?
It all depends, I think, on when a user edits the original. If they make the album and upload it, it would be fine. If they then edit the original and remake the album it again, presumably, should be fine - with a new hard link in the output (?). Only if they edit an original but don't remake the album but then upload it again, for whatever reason, would it fail.

Too many possible things to consider at this time of the day, I need coffee

Windows and locked files in particular and other OSS in general, what would happen should the original be open in another application? Nothing maybe, as long as you don't do a 'save it just to be safe' operation before closing the other application.