eSellerate install failed with error: -2003

[susan42]

Well that was a wasted morning.

Took me 4 hours of struggling to get this to work. The L&L instructions are confusing, spread across multiple pages, and at times are written for users who spend a lot more time with this stuff than the average writer. I was unable to delete the EWSMAC.framework file at all - my mac just decided that, despite being the admin, I should not be able to do that. Even after a disk utility run permissions run it still didn't work. And yes, I do know how to edit permissions on a folder.

Finally I restarted about 3 times after running disk utility and it suddenly decided I could delete files again. So if anyone is getting hung up on deleting that EWSMAC.framework file, make sure you run the disk utility to "repair disk permissions" and then restart at least once. It seemed to take me more than once.

I also ran the esellerate engine update from their web site. I don't know if that also contributed to solve my problem, but it didn't solve the problem immediately after I did it. The problem was only solved after I was finally able to delete the file. I will note that when I ran the esellerate engine update it seeemd to remove the EWSMAC.framework file from the other locations where it had been, so that it only remained in the main framework folder on the hard drive. So perhaps users should update the engine first, then delete the file, then redownload scrivener.

[aeratcliffe]

I assume I experienced the problem (although I did not note the error number). But, it is leading me through a 213 step process to delete the file EWSMac.framework. Something sounds wrong here. Comments?

[KB]

I'm glad you got it to work. Fortunately, you're in the minority and most users have got it running very quickly after following the instructions on the website. It sounds as though the permissions issues on your computer were more serious than those encountered by most users. I'm interested in which part of the instructions you find confusing exactly? We are, in fact, getting lots of emails and tweets from users complimenting us on how easy it was to resolve these issues thanks to the messages that Scrivener now provides (since I updated it yesterday), walking users through the issues, and thanks to the instructions on the site. But I'm happy to look at any particular areas you found confusing to evaluate whether they could be made clearer. The instructions are spread out across three pages because each deals with different issues. Users only need to go through every page in situations where things go really wrong - and as I say, it sounds as though you were particularly unlucky, as your computer's issues were so bad that it wouldn't even let you delete a file.

Given the level of frustration and, in some cases, hostility, that these errors have generated, I would like to reiterate here that the issue is caused by permissions issues on users' computers conflicting with the update to the third-party frameworks we use for checking registration and activation, and that this is not something malicious or incompetent on our part, as some seem to assume. We have no control over permissions conflicts that arise on users' computers, of course. This is the first time we've had significant issues with an update involving eSellerate, as they are usually solid, and as a small company we have no choice but to rely on a third party for our activation and serial number schemes. We are of course very sorry that our users' time has been wasted by trying to sort these issues out, but we are here to help and only an email away. Our time has equally been taken up in trying to help users with these problems, and obviously that is not ideal for us either. I have updated Scrivener to try to hand-hold users through the process where possible before referring them to the website instructions, which has solved the process for the vast majority of users who were experiencing problems, and will continue to monitor issues users have and attempt to add code where possible to hand-hold users even further.

Ultimately, of course, computers do from time to time have problems. The issue here seems to be that a lot of users have updated from Lion to Mountain Lion in the last year, since 2.3.1 was out, which has caused permissions conflicts on many computers (something rife on the Mac), and as 2.4 introduces an updated eSellerate engine that has to be installed, it is running slam-bang into these permissions issues. We are in contact with eSellerate to see if there is anything they can do on their end to make resolving these issues smoother, too.

[KB]

I assume I experienced the problem (although I did not note the error number). But, it is leading me through a 213 step process to delete the file EWSMac.framework. Something sounds wrong here. Comments?

Woah, 213 step? That definitely sounds wrong - that suggests that it has found 213 instances of the EWSMac.framework on your computer, which really shouldn't be the case. Could you please email us at mac.support AT literatureandlatte DOT com and mark your email for my attention? I'll put together a special build for you which will analyse the issue.

Thanks!

All the best,
Keith

[aeratcliffe]

Thanks to Keith for the quick follow up and support. All is good now and, yes, there were 213 instances!

[Strangechilde]

Hi there,

Running OSX 10.7.5 here. I just downloaded the update. I encountered the problem, the software walked me through to find the folder I needed to trash, did that, and everything is fine. Just wanted to let you know that it worked for someone!

[KB]

Phew! Glad it got you up and running!

[matt]

Hi Keith,
I encountered the same problem on updating today, but deleting the folder Scrivener guided me to solved the problem. Certainly much easier to deal with than other times I have encountered similar permissions problems.

One small suggestion: the first time the wizard popped up to guide me through the process I thought, "eSellerate issues, this might take a while, I will deal with it later"... unfortunately, Scrivener gave me no way to Quit without going through the process.

As it turns out, it was a 15 second fix... but it might be worthwhile to add a Quit button onto the window also in case users want to deal with it later.

Regards,
Matt

[tormodg]

Right, to anyone who is still having this problem, please try re-downloading and re-installing Scrivener from our web page:

http://www.literatureandlatte.com/scrivener.php

This version now checks for any permissions issues in your ~/Library folder and attempts to fix them if it comes across them. It will also walk you through deleting any files or fixing permissions if it is unable to do this automatically.

I updated Scrivener today to version 2.4.1 (via the application check for updates feature) and after reading through this entire thread it seems there are still issues.

The error I got was the -2003 error.

1) The popup was unable to open a Finder window. Nothing happened.

2) It took a while for me to read through the various support options. It was only in this thread, after about 30 minutes of reading and trying things, that I realized there are several folders to check.

3) This was actually more problematic than it may seem, because I had a different ewsmac folder ("EWSMac-GC.framework") in my user library framework folder. I spent a while trying to delete that, which obviously did not work.

Finding and deleting the correct folder worked.

What bothers me is that the info material I found suggested copying and pasting ~/Library/Frameworks into the Finder "Go to folder" feature but that is indeed the user library on Mac and not the root Library. This disctinction is mentioned several times but it is not clearly repeated every time you ask people to check folders (for example in the post I quoted at the top of this post).

The correct thing to copy/paste is of course /Library/Frameworks without the tilde (~) - which is actually correct in other material I read.

The instructions are spread out across three pages because each deals with different issues. Users only need to go through every page in situations where things go really wrong - and as I say, it sounds as though you were particularly unlucky, as your computer's issues were so bad that it wouldn't even let you delete a file.

At least it would be a great idea to compile all the various suggestions into one document, and delete all the stray alternatives. The make a step by step walkthrough where you begin by listing the possible folders users should look in, and how they can get there.

Given the level of frustration and, in some cases, hostility, that these errors have generated, I would like to reiterate here that the issue is caused by permissions issues on users' computers conflicting with the update to the third-party frameworks we use for checking registration and activation, and that this is not something malicious or incompetent on our part, as some seem to assume.

I have high regards for this software and it is frustrating to see the dev and assistants dodge bullets by claiming it's a problem on users' machines when obviously it is a problem with the software not being able to update itself. Users do not care whether it is your app or a third-party widget you are bundling with it. There were no permission issues on my machine so stop pretending that it is the only reason why people have problems updating.

While there is no excuse for hostility, I must admit I am a bit disappointed in your handling of this issue. Most of your users are not computer wizards and even locating the /Library folder can be a daunting task.

[AmberV]

I have high regards for this software and it is frustrating to see the dev and assistants dodge bullets by claiming it's a problem on users' machines when obviously it is a problem with the software not being able to update itself.

Out of curiosity, how else could this be phrased? If Software X needs to write a file to Location Y, and Location Y's permissions are broken in such a way that Software X cannot do that, how shall it just "update itself" as you put? It cannot. That is what permissions do, they prohibit you, and by extension your software, from doing something. Ordinarily these are set up to protect your system from mistakes and malware, but if the system gets broken and starts "protecting" areas it shouldn't, isn't that by definition a problem with the user's machine? If every piece of software could just override permissions and update itself regardless, there would be no point to having permission flags on files and folders at all.

Perhaps what you are reacting to is the perception that "blame" is being shifted. There isn't really much to blame here, at least on a personal level. If anything is to blame for this particular problem, it was a botched OS X updater script that damaged permissions a while back.

[Foxtrot]

Downloaded the update on my MacBook today and got the error - followed the instructions step by step, no problem, all sorted.

Didn't try to pretend my problem was different to others because of my particular software skills or incompetence or simply inability to follow simple instructions.