IPhoto 6 getting on my nerves, will v8 help me?

Question

Hello,
I've been using iPhoto 6.0.6 for a while now for organising my photos, and uploading them to Picasaweb and/or Facebook using the 3rd-party plugins.
The 6 version has everything I need (as far as I know), but it also has a number of 'features' that are getting on my nerves, and that have me wondering if they persist in the current version (which I am not going to buy just because it has more bells and whistle, and eats up twice as much space for themes and such... :-/ )
1) Something I grapple with every time I add photos: even when instructed NOT to add colour profiles to imported photos, I find that a good part end up getting a copy in the Modified folder. Mostly vertical ('portrait') pictures, but curiously not always all of them, and it depends on the camera. I don't want those doubles (MANYmpix cameras eat hddisk space as it is), so I spend my time telling iPhoto to 'revert to original'. Correction, that's not enough (they'll just come back!), so I empty those directories in Modified, then lock them, and only then instruct iPhoto to 'revert to original'. This takes way too much time ... and frankly ... display orientation could be a metadata flag, not an edit of the picture data!
2) Today, I added about 1Gb of pictures taken with my new dSLR, already sorted and selected outside of iPhoto, on an external harddisk. I'd decided not to import those pics in my iPhoto folder, but leave them on the external. I noticed that iPhoto had made an alias to each file in the Originals directory, plus a bunch of files (copies) in Modified. So much for "not importing into the iPhoto library...!). Long story short: I did as above: trahsed the copies in Modified, locked the directories they'd been in, relaunched iPhoto, selected all new photos and instructed it to 'revert to original'.
SURPRISE
I started getting yells about missing files. Files that had been there moments before, but were now, indeed, GONE. Gone from the external, while the alias in Originals persisted! I'm well aware that I trying to do something unsupported in iPhoto, but that shouldn't have resulted in file deleting outside of the iPhoto library!
I'll report this as a bug, but I'd appreciate if someone with the latest version could try to see if s/he can reproduce the issue.
3) Creating of aliases to photos not imported into the iPhoto library
4) if a (vertical) photo has to be rotated to be displayed correctly, its thumbnail (typically having the right orientation) will be rotated too, ending up in the wrong orientation
5) I organise my photos in albums, which are stored in folders (maps), usually per year. New albums are always created in the 'root', so have to be moved into the right map. Impossible to put them at the end of the existing list in the target map. The only way I found to put them there is by putting them at the fore-last position, and then move the last album 1 position up.
Feedback on this would be much appreciated.

Answer 1

I'm not sure you understand it. Witness the whole rotation issue.
Please don't make the mistake of taking me for your average computer illiterate. I understand fully well that the orientation flag as recorded in the EXIF data is only to allow applications to open the image in the intended orientation. I'd hope that those $$$ apps you mention do just that. What happens afterwards, is indeed undefined. I disagree with iPhoto's stance to impose an unasked-for edit onto the user, for a simple operation that could in fact simply be done on the fly each time the photo is displayed. I find that approach to be more consistent with an app that is not primarily an editor, but an organiser.
I also disagree with the feature that it will keep doing the operation (and storing a modified file) even after I tell it to revert back to the original. The way you're explaining things, that command is de facto senseless on pictures with the orientation flag set to vertical, as iPhoto might re-edit the file immediately after finishing the command.
The folders in my Modifled directory are write-protected, but perfectly readable. They're just empty. iPhoto is designed to handle that: it will display a place-holder for pictures it cannot find in the expected place (as stored in the XML file AlbumData.xml). That's explicable behaviour. A more intelligent app would proceed to find the original, but in iPhoto the "revert to original" command is required to do so manually.
That's about all there's to it for photos that were imported into the library.
NOTHING in that behaviour explains or even allows to suspect that when files are 'Referenced' as you call it, the original will get unlinked when iPhoto tries to access ... the modified photo it cannot find. Remember, for truly imported files, it stops trying and shows a placeholder when a modified file is missing. It does not unlink the original file.
Please note that there are also unintentional reasons why a file could go missing from somewhere within the Modified folder. Would you be happy your original got lost too with the explanation that something unexpected happened? Or would you consider that iPhoto should have guaranteed that nothing it ever does will cause a change to your original, in other words, that you'd not have lost that original picture?
You confirm my hunch: the Calendar function is to get at (the "origininals") of all pictures taken in a given year. Not for making a meta-organisation of your pictures (remember that each photo can be in an unlimited number of albums, but each album can only be in a single place. (This may be hard to fathom for someone who's only used to the almost flat organisation of files under Mac OS X, as opposed to other Unixs?)
My gripe is just that appending an album to (the end of) a list of albums in a folder takes more operations than should be necessary.
As to the "some system to tracking" ... full filenames are stored in the aforementioned XML file. It would have been easier and probably more robust to store the path to where the file truly lives in that file, rather than the path to an alias to that file. If not only because aliases also take place on disk (and proportionally more than a photo, in fact, even if they're showed as being 0 bytes in size!). I'm still quite convinced that it's something in the kernel-level of aliases that's responsible to what happened to me yesterday. The Unix-side of OS X doesn't 'understand' aliases as well as the 'Finder-side' understands Unix soft- and hard-links.
You know what a really agressive problem-solving method is? Dunking the computer all together...
Yesterday's solution for keeping the files where I want was simple, in the end. I surrendered, and imported the pictures into the iPhoto library. But then, aside from the tried-and-true process of emptying and write-locking the folder in Modified, and doing a revert-to-original on all imported photos, I replaced the newly created folders inside Originals with symbolic links (NO Finder aliases!) to the true original location on the external harddisk. I'd had a slight doubt whether iPhoto would or would not accept this (by doing an @n@l check that would be too complicated to explain here, and utterly senseless), but no problems there.
I'd have preferred to modify the XML data, but this workaround was faster and possibly less problem-prone.
Now, I'm going to hijack my thread a tiny bit. As mentioned, I use iPhoto to organise my pictures, add some comments, and most of the time, upload them to a Picasaweb album.
There are 2 'on-my-nerve' issues with that, one new from yesterday, which seem suitable to discuss in this thread.
A) the uploader plugin claims there's a new version, but upgrading only installs the standalone uploader (plus a bunch 'updaters' in system places without as much as mentioning it: gogole bad!). Has anyone managed to find an updated version? A quick websearch yielded no answers here.
B) The new thing, which I"m very excited about ... I was uploading the 400-some photos of my last trip, and adding some locations to photos already in picasaweb, for once using Safari. To be exact, I was scrolling through satellite imagery of the Waddenzee, following the ferry route we'd taken, when everything froze in a way I rarely experience (mouse included). The thumbnail image of the image being uploaded seemed corrupted, the only other indication something had gone wrong. The panic log indicates a crash occurred in the display driver or some similar lowlevel location. I then installed the latest security patch (005 ?), which apparently contains some protection(s) against boundary issues in the lowlevel display handling. I don't know if there's a link, but I had to upload the remaining 60 photos by batches of 6 at the most, each time terminated by a message that picasaweb was not available.
Does this ring a bell? Could the uploader be doing something that triggered the issue that's worked around in the latest security release (and caused the KP), as a result of which the upload process now terminates with an error? Remember, I uploaded more than 300 photos in a row and without a glitch before the KP, so it's reasonable to presume that my iPhoto hack isn't the cause here (in fact, I upload reduced versions, so the uploader first creates those, and then upload those copies, which are stored I have no idea where but probably not in the iPhoto library).