OMFG.
There are days when it doesn't pay to check my inbox before I fall asleep, as while I was nestling into the pillow I kept randomly laughing at the ramifications of the below. My brain wasn't going to drop it until I'd dragged myself to the computer and forwarded it onto a few like souls who'd also appreciate it, and leave myself a note to write a post...
Anyway, I recently filed a bug [radar - #4273090] with Apple about how Preview breaks its bookmarks to files when their file path changes because it doesn't refer to the file via its file system node, and they replied. Quelle surprise! Unfortunately, the reply was less than encouraging.To quote:
"NAME REMOVED: Engineering has determined this issue behaves as intended based on the following information:
"If you move the file, how would Preview know where you’d moved it? This kind of thing only works with applications because of the launch services mechanism and the Finder. Since Preview isn’t running all the time, it can’t receive notifications of when every file on your disk is moved, and you probably wouldn’t want Preview being launched every time you move or rename a file."
Oh my fucking god.
Will R.
That rhythmic thumping you're hearing is the sound of a thousand developers across the world beating their heads on their keyboards. Since everyone hates being excluded from a joke, and you may not be a developer, we'll quickly go through why the title of this post is OMFG...
Some time ago I mentioned I had a little side project going, whose goal is to map out exactly what the hell was going on at Apple when it came to Quality Assurance in their software from the outside. I think it'd be a worth project for someone to focus on hardware too, but I'm primarily limiting myself to the black box that is their development process.
It's been kinda fascinating, as from what I can tell, in some groups they are fairly up to speed with modern practices, and in others they're in the development dark ages -- for all intents and purposes trying to scale shareware development models up to a multi-million-dollar desktop environment. It's no real secret I've been soaking up what I could where I could and cross-referencing it, and Mac devs will send me all sorts of data points to feed the monster.
I just throw them all in to look for commonalities, so that I am better able to catch real problems versus axes to grind, and one of the more common issues involves aspects of bug reporting and resolution, and the above is one of the more amusing examples I've come across because the ignorance is so pervasive. You'll note I removed the name from the reply above, as I'm guessing it was someone forwarding on the engineer's reasoning, and throwing their name out there wouldn't be fair.
There're more than one misunderstanding in the engineer's reply, but we'll try to break this down a bit without beating you over the head. In Mac OS 10.4, Apple added a new feature to Preview.app called "Bookmarks", which was a nice touch.
The idea was to allow you to mark your place in PDFs, so you could pick up where you left off easier, or note something you want to come back to. Depending on the type of content, the alternative would be to commit the page number to memory or search. It's much easier to just open Preview.app and select the bookmark from the menu, which then opens the PDF and takes you to the desired page.
The problem, and the reason why the dev above filed a bug, is that whoever worked on Preview.app is storing hard-coded file paths to point to the file, such as:
/Users/drunkenbatman/Desktop/OMFG.pdf
This works great as long as the PDFs never move, however if you bookmark a PDF you have on your desktop, and then later move it to another folder, your bookmark is dead in Preview.app.
Luckily, Apple engineers foresaw this problem and implemented calls in Mac OS to abstract the path from the file itself, so you could have a persistent reference to a file. They brought them to Mac OS X, and aside from a horrifyingly-incendiary technote have generally encouraged their use since. For some extra overhead and cycles, you too can store a reference to a file that'll persist in your app instead of just storing the current file path.
When the Apple engineer running around authoritatively closing bugs had gotten past chapter 3 of whatever book they're learning to program applications on OS X with, they'd know this. I know this, even though I had to look up the exact calls (Aliases.h), and someone at Apple would have to be suitably desperate to allow me to run around closing bugs, let alone engineer software they're selling. This kind of crap is pervasively damaging to third party dev morale, as a normal user never sees what they're often dealing with.
Is on us.
Posted by drunkenbatmanOctober 02, 2005, at 02:49 AM
Comments (52)
Posted by: David Appleyard at October 2, 2005 03:14 AM
What is the world coming to?
Posted by: Devon Shaw at October 2, 2005 03:20 AM
I actually encountered this very problem a few weeks ago and it prompted a WTF (not an OMFG). While not a developer myself, I was under the impression that Mac OS X used an omniscient system to keep track of the files themselves, and alter the paths accordingly whenever they were moved. Hard-coding them in solitary locations (such as the desktop, where nearly every file imported on this computer resides at some point) seems kind of... MS-DOSsey, and quite clunky. I assumed (ass+u+me) I was out of line for expecting such a fundamental principle to function correctly, and like a normal consumer I passed it over and worked around it.
Yeah, count me as one of the thousands banging a head on the keyboard repeatedly until it gives way to the squishy sound.
Posted by: Carl at October 2, 2005 03:30 AM
even apple doesn't know about inodes? shit man, we're fucked.
Posted by: Rosyna at October 2, 2005 03:33 AM
Carl, we're all in this hand basket together. Might as well enjoy the ride.
Posted by: cameron aka desk003 at October 2, 2005 03:41 AM
I see Paris, I see France... Yeah, well, you know what comes next.
Posted by: DoG at October 2, 2005 04:05 AM
If I am not mistaken, the problem lies in the fact that files do have unique identifiers that are persistent when moving a file within a HFS volume. Though I haven't dug very deep, I doubt this works very well when moving between HFS volumes, or even worse, moving from/to a different file system, like FAT.
So, in the end, it seems like the Apple engineers made the right choice by not confusing the user with it working sometimes and sometimes not.
Though generally, what kinda gets on my nerves is that when you move a file, and aliases or symlinks point to it, there should be an easy and painless way for the OS to help you find it again, given spotlight and all.
Posted by: Rosyna at October 2, 2005 04:15 AM
Well, it is impossible to move files across volumes so it isn't an issue. It's a copy and delete operation, not a move operation.
Aliases do find the original file when you move or rename a file or any component of the path.
Posted by: l61ronny at October 2, 2005 04:32 AM
I don't get your funny joke.
Storing the bookmark as an alias would be a really dumb idea, since they are only available on HFS(+) volumes.
And this bug is more or less like complaining about a webmaster moving away a web page after you bookmarked it.
Posted by: Omar at October 2, 2005 04:46 AM
having it not work across FSs is not an issue. The solution Apple came up with is elegant, it checks the path first, if it doesn't work, then it checks the inode. I'm just flabbergasted this engineer doesn't know about inodes... We are, indeed, fucked.
DB, have you replied to this mail? Do you have any way to do so?
Posted by: Joshua Voorhies at October 2, 2005 04:47 AM
Maybe Apple, in rapidly expanding it's R&D with their increased revenue, is taking in a lot of non-Mac engineers, who aren't yet "indoctrinated" with Macintosh culture.
The words read as if written by a just-out-of-college software engineer who grew up on WINDOWS.
Posted by: mikeash at October 2, 2005 05:02 AM
Aliases will work for any filesystem. They may not be able to track a moved file on all filesystems, but they will at the very least fall back to a path-based approach, so you're certainly never worse-off than before.
Coincidentally, I've been doing some work with moving over to aliases instead of paths for persistent storage in a project I'm working on. Not only is using aliases and moving from aliases to paths and back (so you can use APIs that want paths) easy, I would dare say that it is nearly trivial to write the base code.
On the other hand, nobody with any amount of experience with Apple's bug reporter expects it to be a font of useful information. Whenever I get an e-mail saying that Apple has added information to one of mine, I always cringe, and it's almost always justified.
Posted by: Clint at October 2, 2005 05:06 AM
Storing the bookmark as an alias would be a really dumb idea, since they are only available on HFS(+) volumes.
OS X only runs on HFS+ & UFS & Apple is dropping UFS. BUG.
Posted by: Pius at October 2, 2005 05:06 AM
Exactly this behaviour works for the files in the MRU list in every Document-based Cocoa app. IIRC, it didn't work in 10.0, and they fixed it at some point in-between.
Posted by: Skatch at October 2, 2005 05:07 AM
l61ronny ,
No, it's not. It's complaining that some of Apple's own engineers seem to lack a basic knowledge of OS X APIs.
And it's not a dumb idea either. iTunes has shown this successfully. You can move your MP3s to your heart's content and it will keep track of them. Why would you argue that Preview.app shouldn't do the same? I see no reason to burden the user with a task the computer can take care of itself.
Posted by: Pete at October 2, 2005 05:38 AM
While not a death knell, this is some type of bell tolling, is it not?
Posted by: at October 2, 2005 05:53 AM
Maybe aliases are going away soon... FAT32 for MacTel?
Posted by: stam at October 2, 2005 06:17 AM
Well, even if you weren't a programmer, you would've know this was possible if you'd actually used Mac apps. As every app using the "Open Recent" File submenu demonstrates, you can still open these documents even if the files have moved in the vast majority of apps.
Perhaps this tech support person has never used a mac before? Which is even scarier.
Posted by: uv at October 2, 2005 06:31 AM
I ran into that too, and being a Windows person didn't think it a was bug...
Although one other thing is that there's also the "default bookmark" which is one that is automatically created - when you close a PDF, it will remember the page you're at. That also isn't saved if you move the file, and I was quite sure that this sort of thing should have been in the resource fork of the file (since it's per-file, is system specific, and shouldn't be a part of the file itself).
And let's not forget the horrible GUI for managing those bookmarks - for example, you can't select multiple bookmarks to delete.
Posted by: l0ne at October 2, 2005 07:25 AM
Plus, we all have Nathan's own NDAlias class on the Cocoa side of things now. http://homepage.mac.com/nathan_day/pages/source.html#ndalias
Posted by: bonaldi at October 2, 2005 08:47 AM
This is *shit*. God I hate path-based filesystems. Worse, tho, is that NeXT, er, Applecan't even make path-based file referencing work!
Posted by: Skorp at October 2, 2005 09:03 AM
My weekend is now ruined.
Posted by: Laurence Harris at October 2, 2005 10:09 AM
This is just another example of the fact that no matter how obvious something is, some people still won't get it.
Anyone who thinks Apple shouldn't rely on aliases in their applications really doesn't get it. And anyone who thinks they shouldn't use aliases because persistent nodeIDs are only supported on HFS+ file systems really *really* doesn't get it. If that were rational logic, and we shouldn't use any feature of HFS+ that isn't available on UFS, then why have HFS+ at all? These kinds of statements come from people who don't have a clue who makes up the primary Mac market or how they use their computers. And what kind of business plan is based on designing your product without a clue about how the bulk of your customers *use* your product?
However, it really is discouraging when Apple's own engineers don't get it.
Posted by: Oliver at October 2, 2005 10:17 AM
Apple's bug system is useless.
Whenever i try to update the currency rates in calculator.app, it crashes. Having looked around the web, I know I am not alone. Seems to affect lots of 10.3 users (more or less since 10.4 was released). Deleting cache or preference files doesn't solve the problem. One user discovered that it has something to do with the link the app uses being broken - most probably Tiger (dashboard) uses a new one, making the old one obsolete in apple's opinion.
But it's a bug. A rather annoying one that seems fairly easy to fix. I've reported it on numerous occasions (basically everytime the app crashes when i try to use the feature), as have other people. No response from apple, and no fix.
So what's the point of having a bug fix system?
Posted by: Jay Tuley at October 2, 2005 11:18 AM
I agree with you DB, OMFG!
Posted by: John at October 2, 2005 02:26 PM
FYI, forget about inodes as a means of "tracking" the location of a file. This is because A) most Cocoa file routines delete the existing file before saving the new one (e.g. NSArchiver). So whatever inode you were tracking won't exist as soon as the user saves a new version of the file in the same location with the same name. In this case, hard paths win. B) If a user buys a new hard drive and clones their stuff over, all the inodes change. What you were tracking now points to some random file on the new drive.
Aliases, however, are superior to either. The Alias Manager uses all kinds of heuristics to find the original file including type/creator (remember those?), creation/modification date, and size. The downside? Resolving an alias is REALLY slow. Like, thousands of times slower than just using the hard path. Also, there's no Cocoa class to mimic the functionality of aliases, so you have to figure out how to work with handles, resources, and such if you never have (aliases harken back to Ye Ole Classic Mac OS).
The one true solution is for Apple to provide a file location class, NSFileLocation or somesuch. This little guy knows about the hard path and looks there first. If the hard path isn't there THEN it falls back to the slower but smarter alias manager, and this all happens behind the scenes.
Someone should file an enhancement request for that...
Posted by: Muriac at October 2, 2005 02:37 PM
That's fucked. This sort of thing pisses me off when some random Windows user doesn't know any better, but to think that Apple is employing at least one such ignorant software engineer is outright depressing. OS X has a long, long way to go before it can live up to Apple's hype. It's not getting there anytime soon with ignorance like this at the helm.
Posted by: Courageously Anonymous at October 2, 2005 03:54 PM
Could it be that the engineer that responded to the bug is an expert when it comes to PDF and not when it comes to all the features of the Carbon File Manager? Why would anyone expect every single person at Apple to be an expert in every single technology at the company? If you haven't noticed, there's a lot of them.
Did the original filer reply to the bug and explain how aliases work for this case?
Posted by: Anthony at October 2, 2005 03:59 PM
Why would anyone expect every single person at Apple to be an expert in every single technology at the company?The person going around throwing out bugs should have at least a minimal understanding of how the APIs work.
Posted by: Wes McGee at October 2, 2005 04:11 PM
You know the funny thing... with all of this bitching about a Windows mindset, at least since Windows 2000, it borrowed that useful Mac/Unixy feature. Of course, it's a more complicated implimentation with the constant system monitering of file changes, rather than assigning it an unchanging number, but it works better than back in the 9x days where a dialog box comes up saying "Searching for target file..." and more often than not it links the shortcut to the wrong file.
Look up "Distributed Link Tracking" or read this article in Ars. DLT works even after I rename the file, move it all over the place, or change the contents, and if I delete the original, Windows no longer tries to reassociate the shortcut to the wrong file.
Now, back to Apple forgetting the capibilities of its own system... yep, "OMFG, WTF?!!" is the correct response.
Posted by: 2.STL-DX.B11 at October 2, 2005 05:05 PM
Oliver,
At least yours has the good manners to crash, so you know it's truly shagged. Mine just comes back with an error if I try and update the rates - "Unable to update the currency exchancge rates at this time"......One day it worked, the next it did not. "Last updated 24th August, 13:10". It's like the clock on the Titanic.....
See? They can' even get the computer to fuck up in a uniform manner.
As for this whole pdf/preview thing, it's yet another area of concern. With everyone sucking on the iPod teat, it's obvious that sloppiness is spreading like wildfire. I've taken to writing random swear words in the crash reporter since it is obvious nobody is listening. A bit of bad language and gratuitous profanity never hurt anyone (cue lightning strike).
Posted by: Alan at October 2, 2005 06:08 PM
and this bug is more or less like complaining about a webmaster moving away a web page after you bookmarked it.
This is more like a Webmaster moving a resource, but not providing a proper HTTP status code, and then claiming the status codes don't exist.
Sad as this is, when you have a company as large as Apple, you're going to get personal who aren't up to snuff. The engineer may spend all day in a shell or X11 land and may never have been exposed to this (superior) feature of Apple's OS. The person forwarding on the engineer's reply probably doesn't care a whit about path abstraction, APIs or anything technical, and is just trying to close out tickets in their queue before heading to lunch.
The proper response, after you've OMFG'ed to yourself, your friends and your website audience, is to open a new ticket, reference the old and explain why the engineer's response isn't adequate.
Polite persistence is the only way to deal with things like this. Eventually the engineer will either realize they were wrong, or get sick of dealing with it and pass it on to someone who might care.
Or they'll keep closing the ticket, at which point you take your empty vodka bottle, fill it with gasoline, and molotov the engineer's desk.
Posted by: Rosyna at October 2, 2005 07:37 PM
John, in the case of atomic file saves there exists FSExchangeObjects which swaps the location of two files and makes it so all FSRefs point to the new file instead of the old one.
If the file hasn't moved, been renamed, or been deleted, then resolving an alias file is really quick since it consults the path first. It's only when the file has moved significantly that it takes a large amount of time to resolve an alias.
If you clone your HD which I've done many, many times (and actually just did last week when my HD died) as long as the path of the new HD is the same, all aliases continue to work. And when the alias is resolved there is an update flag that tells you whether or not you should update your stored alias reference with new data in order to make Alias resolves in the future much faster.
Posted by: Tom at October 2, 2005 09:52 PM
Well, Aliases.h has API's that have been deprecated by Apple in 10.4 along with many of the older FSSpec-based calls. See
So you need to be sure to read the header file before using it in order that this or any replacement functionality can be properly understood. I'm certain the abysmally ignorant Apple "engineer" (why are they called engineers anyway?) has never read a header file in his life.
Posted by: Levi Aho at October 2, 2005 09:57 PM
AFAIK, this could be done with any un*xy type system filesystem. (Thoes with inodes, anyway.) Of course, in un*x we don't bother. At least not that I've seen. I wonder why that is.
Posted by: Ryan at October 3, 2005 06:54 AM
Clint/anyone: is Apple really dropping UFS?
Oh happy days!
Posted by: Mac-arena the Bored Zo at October 3, 2005 07:08 AM
to John (re: NSFileLocation): that behaviour would be inconsistent with the Alias Manager. that's bad. it should just wrap Alias Manager.
Posted by: Jens Alfke at October 3, 2005 11:38 AM
To Clint: You are partly correct, in that OS X only supports installation of the OS onto HFS+ and UFS. But user documents and even entire home directories can be on many more types of local or networked filesystems, from FAT32 to NFS to SMB to WebDAV to ISO-9660. Many of these don't support persistent inode numbers, but there the Alias Manager falls back to using paths.
To John: What you're describing for the hypothetical NSFileLocation is the way the Alias Manager already works: it first looks for a file at the old path. (It's always had to, because a lot of apps save by creating a new file and replacing the old one, without using FSpExchangeFiles to preserve the file ID.)
Posted by: Evan at October 3, 2005 12:23 PM
Forgive the potential stupidity of this question (I being only a lowly journalist and not a developer), but what about changing the locations of files resulting in dead linksin another app like iTunes for example?
How would this situation differ from preview. I'm still using 10.3 so I don't know if they've fixed this problem in iTunes specifically.
- Evan out.
Posted by: Laurence Harris at October 3, 2005 01:31 PM
>The one true solution is for Apple to provide a file location
> class, NSFileLocation or somesuch. This little guy knows
> about the hard path and looks there first.
Starting in (I think) 10.2, the Alias Manager was changed to try the path first and then the nodeID instead of the other way around as it did prior to 10.2.
Larry
Posted by: Peter da Silva at October 3, 2005 03:15 PM
You know what's really messed up?
Apple is faking the interface to those aliases in HFS+.
http://developer.apple.com/qa/qa2001/qa1113.html
Not only that, but this means these aliases bypass traverse checking, so if you change the permissions on a higher level directory existing aliases that point behind that directory continue to work.
Posted by: Peter da Silva at October 3, 2005 03:20 PM
"Clint/anyone: is Apple really dropping UFS?"
I would MUCH rather they dropped HFS+.
HFS+ has all kinds of shiny features.
But it's flakey as hell compared with UFS. I have NEVER had any UNIX file system since the invention of fsck come back and tell me to back-up and restore or had to use a third-party tool to fix it. Not over decades of being an occasionally abusive computer user and network administrator. I've gone through this dance half a dozen times with OSX and HFS+.
Posted by: craigtheguru at October 3, 2005 03:59 PM
Have you resubmitted the bug report, specifically citing the use of OS X's aliases library?
I never used the bookmark feature and now, while I'd like to use it, I'm glad I know about this shortcoming.
Posted by: Craig Turner at October 3, 2005 08:00 PM
When I first read this, I didn't agree it was a bug. What happens in an application if you're taking care of document versioning by moving files around yourself using the terminal (I tend to work in os x is with gnu/screen running in a single terminal window). Now I can see your perspective, but it's not as cut and dried as you present it.
Posted by: jeremy whitman at October 3, 2005 11:47 PM
The engineer in question, or the guy who instructed him to compose this email should be fired.
Granted, this isn't exactly a bug, if a bug isn't ignorance coupled with laziness....
Posted by: Robert Cassidy at October 4, 2005 02:04 AM
Well, if you have broad knowledge of Apple's development team, this wouldn't surprise you. There are critical parts of OS X Server written by interns. Apps like Preview have very small developer teams, so you really fall back on individual competencies. Apple has been adding developers as a pace that must have easily outstripped the supply of experienced and interested OS X developers long ago. So new hires are Windows/unix/open source experienced, Cocoa is a whole new animal to many of them, and Apple tends to hire rather talented and experienced developers, which means they want to do things their way.
This all sorts out, but it takes a version or two from what I can see.
My $0.02 - it's DEFINITELY a bug. inodes are old-school, they work most of the time, and Mac users are accustomed to moving files and having things just work. As for the arguments for inconsistent behavior - they're a non-starter, the inconsistent behavior is breakage to the user. The less things break, the more consistent it is for the user.
Refile it. Email back to the engineer with a kind note about inodes and examples of Apple apps that don't exhibit this behavior. For example, the recent items menu in the finder. Go try it. If they resist, reply again kindly and cc Schiller and Tevanian. Schiller replies to my emails all the time - he'll deal with it.
Posted by: steve harris at October 4, 2005 03:42 PM
> What happens in an application if you're taking
> care of document versioning by moving files around
> yourself using the terminal
Well in theory it still finds your latest one because the path lookup is attempted first, then only if it's not there then it looks by the direct identifier.
Posted by: cocoaboy at October 5, 2005 05:16 AM
The engineer could be a newbie, of course, or he could be from NEXT, or unix. In any case there is a case to be made that - from the Cocoa point of view - this is not all that trivial, although it should be done in most cases. ( As an aside here it is definitely not done in Safari downloads which I would have thought would be the more obvious bug). The Unix/ Next heads dont really see this as an issue. If Cocoa does not vend these API then the typical Cocoa engineer may not be all that interested in adding the Carbon framework and using what would seem to be exotic API to return these strange handles, using another obscure C (launchservices) level api to open the aliases when you have them, and serialising the reference to the alias to disk rather than a simple path string: bypassing the Cocoa layer entirely.
Since Cocoa is Apple's preferred API they may be hiring people with Cocoa ( Or Java or C#) experience, much as MS may in the future hire developers with C# experience only : and a C#/.Net developer is prob. not going to want to go back to the MFC layer to do stuff whereever possible.
Cocoa is all hard paths and absolute file urls.
Posted by: at October 7, 2005 04:54 PM
Scary.
Posted by: Unteins at November 2, 2005 08:07 PM
Well, as far as bug reports go, yes totally useless. I was crashing Safari 3-5 times a day and filing bug report after bug report. I finally offered to walk the afflicted iBook in and let the developers test on it to determine the source. So far, no one is taking me up on the offer, even though I am at the Cupertino campus from time to time (lunch today even)
Posted by: Tr909 at November 5, 2005 05:34 PM
Cocoaboy has an interesting point of view (cocoa vs carbon perspective). I must say although, this whole metadata thing was a major discussion in OSX' lifespan (See ARS technica). It was almost dead after the transition from MacOS to MacOSX. Some people on the internet were concerned that metadata would rather soon die and now (with tiger) metadata is alive and well again (finder/spotlight).
I agree that this issue is sad. I programmed a little pascal before and try my best on some PHP pages but large portions of my time, i work on graphical stuff and viewing documents and managing projects. Here comes the part where i would like my user experience to be swift and correct, i don't want to be fighting the filesystem with this kind of caboodle, that is why i left windows in the nineties and stepped over to the mac.
When we're talking not from the unix commandline guru's perspective but from the end-user's perspective, making iMovies, managing accounts (PDF etc) en downloading logo's, graphic files etc. this Alias stuff should: a) just work and carefully be continued as the mac experience, or b) be abandoned and HFS for that matter as well... i vote A.
Thanks for a good article, and i hope someone at apple picks this up. The quest for marketshare and expansion can and should not harm quality...
Tr909
Posted by: at January 20, 2006 01:25 AM
how to delete file from old apple computer ?
Hell I have very little experience with developing (and it is mostly web based stuff at that) but even I knew you could do this thanks to a number of applications that do stuff like this.