max's dashboard

There are some key files at /System/Library/SyncServices/Schemas which get installed with the application. Sounds like this is running on a system where the app was restored from /Application, or the system was restored from a backup.

Anyway, re-install Xmarks for Safari - this should solve the problem. Grab the installer from http://download.xmarks.com/download/m...

Thanks for the comments.

Don't hesitate to also fire an email to support@xmarks.com with symptoms etc so we can help on specific problems. – max, on December 10, 2009 00:49

Yep, it's hard to estimate bug visibility based on support traffic.

There's no doubt it's not something you are causing - there's most certainly a bug or unexpected interaction with other sync clients (both ours and other clients of bookmarks). This certainly happens on the Safari client. On the FF side (about which I know a lot less) there are different issues around profiles which get corrupted usually due to FF being force quit.

Each log we get helps us get a little closer tho'. Ultimately the bugs we have not fixed yet are the ones we can't reproduce in-house. The logs help a lot, but we're still figuring some of these out. – max, on December 09, 2009 00:05

Stopping Xmarks for Safari: Go to system preferences (under the Apple menu, top left), click on Xmarks for Safari. Pick the General tab, click Stop Xmarks.

Uninstalling: Download the 10.5 or 10.6 package as appropriate at http://download.xmarks.com/download/all Double click on the DMG file you just download to mount it. Double click Uninstall Xmarks.app

Or if you keep the app: The popup is asking you to allow the app to store your password in the keychain. Either say yes, or turn off automatic sync in the Xmarks prefs.

Step 1 is deleting ~/Library/Xmarks which resets the xmarks sync state. Step 2 if that doesn't work is to try the instructions here http://support.apple.com/kb/TS1627 which resets the Apple sync state.

We've been trying to repro the cases that lead to both of these and will fix them if we can see them happen - despite the fact these show up here a lot they seem to be still rare (going on the 10s of 1000s of users syncing each day without the problem). Hoping to fix tho'! – max, on December 04, 2009 00:35

Hm ok. Let's see if the login attempt is hitting our server. From the xmarks prefs, General tab, change login button, enter username and password, hit login. Now go look at the end of the file home/Library/Xmarks/xmarks.log.txt What do you get? A successful login in the log looks like:

2009-11-24 10:15:32 -0700: Info: POST https://login.xmarks.com/login/signtoken
2009-11-24 10:15:32 -0700: Debug: Response is: {"status": 0, "auth": "long-auth-token-here"}

If you are able to hit the servers but the username and password don't match then it looks like:

2009-11-24 10:15:57 -0700: Info: POST https://login.xmarks.com/login/signtoken
2009-11-24 10:15:57 -0700: Debug: Response is: {"status": 401, "message": "Wrong username or password."}

If they don't match when we get them, but they are correct at your end then something is messing them up on the way. In the prefs Advanced tab, do you have any proxy settings turned on? If yes, do you know what kind of proxy is between you and us?

Another thing to try is in the Advanced tab, try the three different settings for the "Encryption" drop-down. Do any of those make a difference?

Finally try resetting your password at http://login.xmarks.com/account/chang... - set it to something with no international characters (just in case - those should work but let's try anyway) and see if you can login with that.

Let's tackle the blank settings first. Checking my understanding: If you go to the system preferences, and select Xmarks for Safari... that pops up a blank panel? If yes, then quit system prefs, start the system console (/Applications/Utilities/Console) and go through starting the Xmarks prefs again. Let's see if there are any messages on the console at that point.

The error in the log you posted is a straight up failure to make a network connection. Assuming other apps are connecting out fine, we should check the prefs (if we can get the panel working) Advanced tab to make sure there are no proxy settings left behind from previous times. Another change that might make a difference is to set the encryption (same Advanced panel) to either No Encyption or Encrypt all (the default settings uses encryption for login and none for the bookmark data - setting it one way or the other will force all one protocol, removing one possible variable).

Does that same username and password work when you try to login at http://my.xmarks.com ?

Hi rbullockv8: If you have the debug info zip file, send it to support@xmarks.com and mention this GetSat thread (so we can keep track).

the Google Video and Voice plug in, which is very common, is causing osascript some issues?

Hm, errors you see from script plugins *may* be a red herring. I've looked into a couple of quite common and noisy errors just recently and discovered that the scripting framework seems to complain at you about broken (recently this means 32 bit in a 64 bit world) plugins even if you are not using them. This seems to be sort of safe as the errors go to the system console and maybe to your script's stderr... unless your stderr is, one way or another, going to break what you are doing. There's discussion about this dotted around but it's hard to find. One notable common breakage is for folks with Adobe CS going from 10.5 to 10.6 with "Adobe Unit Types.osax" - we get console logs with errors from this as we startup our prefs panel all the time (Adobe has a fix for this particular problem).

Nevertheless I think we need to minimize our use of frameworks as much as possible. Each dependency leads to bizarre bugs with corner case (or not so corner case) user setups. I want to remove all applescript and all pyobjc from our app as soon as feasible (sadly that won't be real-soon given what's more urgent).

> ... more good reasons to use /Application/Support ...

Ok I am gonna move us to /Application/Support on the next release (oh and fix the keychain) (and continue to try to find the sync bugs we can't reproduce that people see here, grr).

About the only thing I would add is that the web based iPhone display could use a little work. Let's say I find some time... Would I be wasting my time, or would you take the html and css and js and perhaps use it if you thought it to be better?

That's not a piece I work on but we'd certainly take a look and use your good ideas if you let us!

The 'reset' is how some people refer to what you had tried already (deleting ~/Library/Xmarks) - this essentially starts our sync from scratch without any intermediate files, using only the bookmarks on the system.

Upload initiates a sign-on the same as any other operation against our servers if it doesn't already have an authentication token.

Yes upload should work like that. I'll take a look at what you emailed to us. – max, on November 19, 2009 18:20

Hi chipmck: The last dialog you posted is a result of the earlier crash - in some cases where we can, we try to recover. That doesn't always work, as in this case.

Your log is really interesting, and I'd like to get a look at the whole thing after a reset. Would you mind doing the following...

* In Safari, File > Export your bookmarks, just in case :)
* Do the 'reset' process you've seen here before...
* Be sure to quit Xmarks for Safari
* remove home/Library/Xmarks
* restart Xmarks
* go through the wizard, enter login info, ...
* assuming you still want to upload... at the 3-way radio button dialog, pick the 'upload' option (3rd one, "discard data on the server; keep data on this computer") else feel free to merge or download
* either way go to the prefs help tab, debug report button, grab the zip file it creates and attach that to an email to support@xmarks.com, refer to this GetSat thread so we can keep track

Finally... when did you start getting this behavior? Was it after an update of Xmarks or does it precede that? Thanks, let's see if we can't get you going again.

Hi nichlas: My experience (and reading of the Apple docs) is that I am able to unregister the two extra Xmarks schemas from Synchrospector and it does not affect other apps which used the main bookmark and folder schemas. In other words, for example, I can unregister the two xmarks schemas and Safari bookmarks are just fine.

Our two schemas only add a couple of fields to the default bookmark and folder schemas. So if they are removed, you merely lose data which only Xmarks is interested in. That's the theory, and that seems to work as expected.

If I were you I'd still export my bookmarks from Safari... just in case :)

The relevant doc is here http://developer.apple.com/mac/librar... in the section "Creating a Schema Extension" explaining that extensions to schemas are local to the apps which register them.

Sync Services ensures that only those applications that use the extension see the entities and properties defined by them. You can even extend existing Apple Applications schemas without adversely affecting other desktop applications.

This doesn't speak explicitly about removing the extensions, but the implication is that the extension is irrelevant to apps which don't care, and as I said, our tests have shown that this seems to be true.

Hi drjcfigue: There's a couple of things you can do which will help identify the problem so we can help. Here's some info you can gather and then email to support@xmarks.com (mention you came from this GetSat post so we can keep track).

(1) If the application is shutting down unexpectedly, the best information is probably in the system console.

* Start the Console from Finder: /Applications/Utilities/Console
* Clear the display to make it easier to work with: View > Clear Display
* Start Xmarks then make the error/crash happen. If something interesting shows up in the console then continue...
* Select and save the error lines: click on the first interesting line, shift click on the last interesting line, then Edit > Copy, then paste into the email to us

(2) If the application runs then there is a lot of useful info in the application debug log.

* Go to the Xmarks preferences, Help tab, press the Debug Report button
* This creates a file Xmarks-info.zip on your Desktop
* Attach that to the email to us

Ah yes I misunderstood about your .app file. It will launch the app if it's not already running, but you make a good point that it could usefully bring up the prefs if already running (or by default for that matter). I wonder if I can detect it was clicked from there... hmmm. Logging a ticket to look into it.

Scripts: Oh my, you're right. Very bad form to not be explicit on the paths or clear the env. Another ticket to look into how the shell env looks under AppleScript. We do get people with mystery install issues, this could be a contributing factor.

Don't get me started on mystery issues we can't reproduce yet.

Looking at the installer bundle, and the list of files in the BOM, I do not see how a zero byte file is made. It has to be that this is only in update. Does the icon keep? Wonder, does "get info" count off the resource forks and meta data for icons and such?

I don't understand your points completely, and am still discovering the many and varied "features" of PackageMaker and the installer. One issue we've almost certainly hit is not incrementing the bundle versions on everything in the install package which I think has led to "update" behavior rather than clean install. Hopefully we've got that nailed in 1.3.2 and beyond.

Perhaps a little chown -R foo:bar post script in the installer would alleviate this? Though installer maker should be doing permissions for you.

Your points on multiple admin users doing installs/updates is good. We do set the ownership to root/admin both in PackageMager AND in a subsequent post-install script (because PM doesn't seem to be reliable about doing it). This should work (the post-install stage) as we do this sudo, and that should work if the user authenticated as an admin (ugh, I hope that statement is true - it does work in our test scenarios).

Ok, so the pref pane is just an agent to the app, got it. My question is, if I move "Xmarks for Safari" elsewhere, will the pref pane find it, and as long as I manually change the login item by removing it and adding it in again, to the newly located app, will that be OK?

The pref pane finds the app fine where-ever you move it (at least, it does when I move it to random spots like ~/tmp). The start-yourself step is done using AppleScript, which does some kinda magic. For example after moving the app to ~/tmp, check this out:

$ osascript -e "path to application \"Xmarks for Safari\""
alias Macintosh HD:Users:max:tmp:Xmarks for Safari.app:

Given that the sripting framework figures it out (~/tmp is not in my PATH, I really should learn more about what's going on here) then this works: osascript -e "tell application \"Xmarks for Safari\" to activate"

Then once the app is running, it's all message passing as I said (we use NSDistributedNotificationCenter - *very* handy for IPC).

The login item seems to need to know the /full/path, so that does need to be tweaked if you move the app. There may be some feature we could use to abstract that away, which would be nice.

I am in favor of putting [the app] in Application Support

That's a good idea. We do get various flavors of grumbling on this issue, and App Support might be the best other location. Ticket open for consideration (there was one already but Application Support is the new best candidate in that ticket I think).

Are you aware Xmarks does not sync all bookmarks?

Oh yes, yes indeed. There's a very long thread about it with a lot of unhappy people in it. We only map the two top level collections named Bookmarks Menu and Bookmarks Toolbar into our sync data model. Historically we started out on Firefox, and then included IE in the mix, then went to Safari. On those first two the data model with those two top level "roots" worked nicely. Safari introduces an unlimited set of "roots". So we have a couple of things to work out: (a) How we map those to other browsers (we just need to pick a policy and then do a bunch of mapping on the fly between browsers). (b) We probably need to change our server data model to make this more natural (for the server and the clients)... that mapping between browsers can get mighty tricky already just with the two "roots" we deal with (sounds simple, turns out to be full of exciting traps).

So we hope to do this, but it's not imminent.

Oo. plutil(1) is handy. Learn something new every day!

Thanks for the thoughtful points - that's several new items in the list of bugs/enhancements. If you have more, send 'em over here or at support@xmarks.com (ref. this thread so I/one of the others can keep track).

Thanks for the update Matt! – max, on November 13, 2009 17:50

Hi DBZFYAM: The specific error Symbol not found: _PyType_Modified was the symptom we were seeing with our version 1.2.x running on Snow Leopard (OS X 10.6). Are you running 1.2.x of Xmarks for Safari (it should say on the About tab of the preferences panel)? You can grab a newer 1.3.x version from download.xmarks.com

Let me know if that's not it.