Skip to main content

how to use dropbox to synchronize windows 7 sticky notes

you may remember awhile back, I wrote up some steps on how to use windows live mesh to achieve sticky notes synchronization. live mesh, sync, and now mesh again, was a great product to use for this purpose because you could point to the folder and tell it to sync it. unfortunately, I didn't find it very reliable and by the comments I read, neither did a lot of my readers.

this morning, I got quite frustrated by a couple of things going on. first of all, no sync! second, digsby! sticky notes and digsby are two things I've come to rely on. there's some talk about a protocol change (or using old protocols or something like that) I read that pointed to digsby's msn having connection problems while using windows live mesh. while live mesh was running, msn would drop off. according to their blog, it's a known issue and will be revised in a future release.

anyway, so here I am. I decided to get rid of mesh in favor of something I've been using awhile and have come to love: dropbox. the challenge with dropbox was that I had to find a way to synchronize the content (yeah that's easy I know) without having the content only in the dropbox folder.

the first thing I thought of doing was writing a script to copy the dropbox content on sync detection. this seemed like OVERKILL when I found someone else's brilliant solution: ntfs junctions.

 

configuring dropbox and junctions

this is a rundown of the steps involved, which is pretty dang easy. so let's get started...

  • close your sticky notes application. make sure it's closed. if it's still running, you'll see the StikyNot.exe process running.
  • create a new directory called "sticky notes" somewhere in your dropbox folder. I just put mine in the root for ease.
  • navigate to the "sticky notes" directory on your computer, where you'll find a file called StickyNotes.snt. (the directory path is c:\users\<userid>\appdata\roaming\microsoft\sticky notes)
  • copy the StickyNotes.snt file to the dropbox folder you created.
  • now get rid of the original "sticky notes" directory.
  • from a cmd prompt, type the following to create your junction:
mklink /J "%APPDATA%\Microsoft\Sticky Notes" "<Full Dropbox Path>\Sticky Notes"

  • once you open up sticky notes again, it'll be pointing to the file in your dropbox folder courtesy of the junction you just created. :)

if you open the path to the original stick notes directory, you'll notice there's a shortcut icon on the folder to indicate it's a junction. if you open up the folder, you'll find yourself in your dropbox folder.

image

okay, now you're syncing sticky notes to dropbox... but what about another computer?  simple.  just run through the same steps above, except this time, don't worry about copying your stickynotes.snt file since it already exists in dropbox.

 

notes

there's one caveat I should mention. the synchronization can't take place while sticky notes is running. you'll want to close your sticky notes application every now and then so that dropbox has a chance to sync your changes.

this applies to computers receiving the files from dropbox as well. as long as sticky notes is running, it won't be able to sync the contents.

Comments

  1. Cloud Sticky Notes is an app that looks and acts like Windows sticky notes but syncs on all of your desktops. Avoid the hassle by visiting www.cloudstickynotes.com.

    ReplyDelete
  2. This comment has been removed by the author.

    ReplyDelete
  3. Thank you, works well! I don't need to close SN, after each change it is synchronized automatic. I use Google Drive.

    ReplyDelete

Post a Comment

Popular posts from this blog

using preloadpkgonsite.exe to stage compressed copies to child site distribution points

UPDATE: john marcum sent me a kind email to let me know about a problem he ran into with preloadpkgonsite.exe in the new SCCM Toolkit V2 where under certain conditions, packages will not uncompress.  if you are using the v2 toolkit, PLEASE read this blog post before proceeding.   here’s a scenario that came up on the mssms@lists.myitforum.com mailing list. when confronted with a situation of large packages and wan links, it’s generally best to get the data to the other location without going over the wire. in this case, 75gb. :/ the “how” you get the files there is really not the most important thing to worry about. once they’re there and moved to the appropriate location, preloadpkgonsite.exe is required to install the compressed source files. once done, a status message goes back to the parent server which should stop the upstream server from copying the package source files over the wan to the child site. anyway, if it’s a relatively small amount of packages, you can

How to Identify Applications Using Your Domain Controller

Problem Everyone has been through it. We've all had to retire or replace a domain controller at some point in our checkered collective experiences. While AD provides very intelligent high availability, some applications are just plain dumb. They do not observe site awareness or participate in locating a domain controller. All they want is the name or IP of one domain controller which gets hardcoded in a configuration file somewhere, deeply embedded in some file folder or setting that you are never going to find. How do you look at a DC and decide which applications might be doing it? Packet trace? Logs? Shut it down and wait for screaming? It seems very tedious and nearly impossible. Potential Solution Obviously I wouldn't even bother posting this if I hadn't run across something interesting. :) I ran across something in draftcalled Domain Controller Isolation. Since it's in draft, I don't know that it's published yet. HOWEVER, the concept is based off

sccm: content hash fails to match

back in 2008, I wrote up a little thing about how distribution manager fails to send a package to a distribution point . even though a lot of what I wrote that for was the failure of packages to get delivered to child sites, the result was pretty much the same. when the client tries to run the advertisement with an old package, the result was a failure because of content mismatch. I went through an ordeal recently capturing these exact kinds of failures and corrected quite a number of problems with these packages. the resulting blog post is my effort to capture how these problems were resolved. if nothing else, it's a basic checklist of things you can use.   DETECTION status messages take a look at your status messages. this has to be the easiest way to determine where these problems exist. unfortunately, it requires that a client is already experiencing problems. there are client logs you can examine as well such as cas, but I wasn't even sure I was going to have enough m