Sandboxing is utterly broken. If you want a real hellride try to load 'sandbox unsafe' Audio Units (read: every non-Apple AU, though many Apple AUs aren't safe either) into a sandboxed application.
There's a temporary entitlement that should allow this. The only problem is, that this entitlement simply disables sandboxing midway through app initialization and the NSUserDefaults system becomes unusable after that.
>Sandboxing is utterly broken. If you want a real hellride try to load 'sandbox unsafe' Audio Units (read: every non-Apple AU, though many Apple AUs aren't safe either) into a sandboxed application.
How does that prove that sandboxing is broken, much less "utterly"? You should NOT be able to load unsafe AUs into a sandboxes application.
And I'm not sure "temporary entitlement" was developed to allow this kind of thing. Sounds like an abuse of it.
I thought there was a way to report these issues to Apple without a public letter. Also, the use of "embarrassing" to describe an unfortunate bug makes this feel like a disingenuous PR stunt.
We reported this to Apple (that's what the rdar:// link is for, to add to the Radar bug tracking system). The "embarrassing" perhaps stems from our frustration and months of dealing with similar issues, but is something that should have easily been uncovered if apple did dogfooding of the technology before forcing it on developers.
I wrote it up as more of a public service announcement to other Mac developers who might be encountering the same issue.
>The "embarrassing" perhaps stems from our frustration and months of dealing with similar issues, but is something that should have easily been uncovered if apple did dogfooding of the technology before forcing it on developers.
The technology was obviously tested by Apple --they didn't just put something out there--, and it was also available for third party testers to test with the betas.
If nobody had found it at that point, why would Apple? Maybe it's not as common as you think.
There is a way. The bottom of the page and the end of the video link you to rdar://problem/12801387 . However, that is not a public site.
I do not agree with your assessment of what "embarrassing" means. This could as easily be an irate developer as a PR stunt. I believe the latter interpretation is more likely.
Here are some other examples of how "embarrassing bug" is used, in a style which is similar to what is used here:
Cloud computing: Amazon suffered a highly
embarrassing bug last spring when part of its much vaunted cloud service went down. Client websites such as Quora and Reddit were temporarily forced offline because they relied on Amazon’s servers - The Independent.
Microsoft's command-line utility for copying files, 'copy', has an embarrassing bug. If you command it to copy a folder into a new location, it instead copies the contents of the folder, and ignores the folder itself. Therefore, it does what you didn't tell it to do, and doesn't do what you told it to do. Therefore, that is an egregious, unforgivable, and incredibly embarrassing bug for Microsoft. -- http://nicholas.rinard.us/2012/07/embarrassing-bug-for-micro...
To fanboys it's only 'embarrassing' when it's the other sides problem. WWGS? (What would Gruber say?)
Also when I used to be a Mac administrator, the Apple private databases/forums would drive me mad. God forbid if you could do a Google search for what you are experiencing and find some discussion! Bugs? What Bugs?
There is indeed a way, but you'll get a better response by stuffing a message in a bottle, and throwing the bottle in an ocean. OTOH, if your issue gets some media attention, an Apple engineer will call you.
It's nice to have a blog post and video demonstrating the bug clearly. If I was confronted to this problem trying to save a file, I'd love to find it on Google.
I don't really care whether or not they call it embarrassing or use their own product as an example.
Not being able to handle legal file names is pretty embarrassing as bugs go these days. Path name handling is very testable, and a known source of problem since forever.
It is a web interface for Radar and all bugs are triaged by the dev teams pretty quickly. Unfortunately you can't see outstanding bugs or track their progress.
I think you hit the nail on the head. It's a PR stunt. It's an add that essentially says - look how smart we are, and this is our product. I mean no disrespect, but it smells.
Just report and it surely will get fixed. No need to call it out as "embarrassing". Especially not as an Software Developer yourself, like you never had any stupid bugs in your code, right?
I could have sworn just a few months ago I read something on HN that the best way to get Apple to acutally fix a bug was to:
1. Submit to radar
2. Submit to open radar
3. Try to convince a developer evangelist on the inside your bug is worth attention
4. Go pimp your bug on social media
I thought it was all unnecessary legwork to get the attention of a company that should be more proactive, but the comments seemed to agree that it was the way to do things. Now that someone actually is doing just that the tide of opinion seems to have turned.
I've shipped plenty of embarrassing bugs in my days! And, had I shipped a bug that likely has to do with escaping characters improperly, I too would have been embarrassed by it. But beyond that, as someone who spent many years dealing with integration testing of Mac OS X, this is the type of bug that would make me cringe that our infrastructure was not setup to catch it.
This is really worded funny. It's not embarrassing to Apple if you post it. It's only embarrassing if they determine it to be embarrassing and as far as I am concerned this is an extremely small use case.
Also can you PLEASE stop saying HTML5. It's soo annoying. HTML5 IS HTML. It could be HTML3 the bug would still appear :)
How is this a small use case? I know a number of people including myself who have spaces in folder name, especially when trying to keep things organized (for example a folder in applications called Web Development would trigger this bug). For a company as large as Apple supporting an infrastructure as large as its app store this most definitely should have been caught long before release.
I didn't say that I or the people I know use OSX. However I made the assumption that Linux and Windows users were similar enough to OSX users in the ways they organize their stuff. Putting the size of the use case aside, It just surprises me that something like this would make it into a production system supporting 10s of thousands of apps and number of which have spaces in their names.
>Sandboxing is required by Apple to be on the Mac App Store. The technology has caused us and our users grief, cost significant development time, and likely lost our business users.
Maybe due to incompetence? On their part I mean.
For one, you are not required to be "on the Mac App Store". You can continue to sell your app outside of it. Heck, very successful apps are sold outside of it, from MS Office and Creative Suite to most of the stuff Rogue Amoeba does.
Second, tons of other apps seem to do just fine on the app store. What exactly makes your app an exception?
We do distribute and sell independently of the Mac App Store, which allows us to offer trials, lets users to easily convert the trial to a licensed copy, and provide bulk or educational discounts. Even with that, ~80% of our revenue has come from the Mac App Store. Users want and expect software to be available on the Mac App Store; I'm sure the support volume we'd get by not being there would far outweigh any we've seen from this bug.
Sandboxing was a technology that did not exist (and therefore was not required) when we started selling on the Mac App Store. This came later, and became a requirement to push any updates containing features.
Lots of mac developers have complained publicly (or privately to me) about sandboxing. Many others have not been able to issue updates, removed major features, or simply removed their apps from the store. There's plenty of information on this on blogs or the developer forums, though many would not speak out publicly against the hand that feeds them. The apps that do well with sandboxing are naturally those which do the least. It would have been easier for us to neuter our app, but we've taken a strong approach to working through all the issues and avoided removing any major features. It would be unfortunate if innovation was sacrificed for security.
We originally planned to have our non-MAS copy not be sandboxed. This creates complications and other bugs for users when offering both versions based on how the sandbox container is maintained and that any bookmarks (aliases) kept cannot interoperate between the two. From all the tradeoffs we see, fully adopting sandboxing is the best option. But, that won't stop me from complaining about all the bugs!
I might came off as a little harsh, but I've seen a lot of "X API is awful" posts before with little content besides some grips and one/two bugs" (which all APIs have).
I'm pretty sure this as to do with "TextEdit" being processed as "TextEdit" and "Text Edit" being processed as "Text" and "Edit" (and maybe neither "Text" nor "Edit" being allowed, while "Text Edit" is whitelisted but for whatever reason tokenization screwed up).
"Whitespace in filename/dirname" issues are typically tokenization issues in 3rd party scripts. Here it's probably related to some bogus lookup in some blacklist/whitelist.
Writing very strict coding guidelines and specs enforced at build time is a real time saver. For example we're using a script which verifies that all of the files/directories we've got control on are only using a subset of ASCII.
If you're a programmer working on the server-side, you have complete control on the naming of files.
Why is it a godsend to use such anal specs? Because external utilities / scripts, on a variety of OSes, will work flawlessly on your files. Otherwise it's all too common to have quoting / escaping issues with this or that script / tool / utility not correctly dealing with space on this or that platform.
When you're forced to let the client pick filenames, things gets a bit trickier. But I still do advice very strict naming conventions for all the files that you have control upon.
Anyone not admitting that a space in a filename can be problematic hasn't been in this business long enough. (Hint: the problem is not what you have control upon, but what you don't have control upon... And that very article is precisely* proving my point).
Exactly. Allowing end users to put spaces into end user document names is a fine feature. Allowing developers to do it is just dumb. There are far, far too many tools (really useful tools, if someone is tempted to argue this bit: please don't, you're simply wrong and I won't engage) out there that presume that path lists are split on whitespace.
There's a temporary entitlement that should allow this. The only problem is, that this entitlement simply disables sandboxing midway through app initialization and the NSUserDefaults system becomes unusable after that.
See last post in: https://devforums.apple.com/thread/155950?tstart=0