My Windows Live Mesh Cluster Fail(pantuso.com)
pantuso.com
My Windows Live Mesh Cluster Fail
http://pantuso.com/2010/11/21/windows-live-mesh-cluster-fail/
9 comments
This reads like it could be a good ad for Dropbox. That version would've been in the file's history. A 5 second repair-job.
My thoughts closely aligned to this, "What, Mesh doesn't provide access to the previous versions?" That is a huge part of the reason I trust Dropbox so completely. They've got my back in case they do screw up.
I use Live Mesh and this happened to me once but every time it syncs, it moves the "old" file to the recycle bin... It just doesn't deletes it! I have to manually delete it, so if shit happens, I can always just look in the recycle bin. Did you search there? =\
That's pretty horrible. I must admit that I haven't "upgraded" to the new version of Mesh yet, due to concerns with it. First, it's not really Mesh -- it's Sync, with a name change. Second, the original Mesh was architected by Abolade Gbadegesin, probably one of the best architects in the industry you haven't heard of (and now an architect on WP7). I don't know who did Sync/Mesh.
I do wonder what would cause such an issue. You'd think that simple timestamps would catch this issue. I wonder if the original poster changed his clock to match the time for this Ignite conference and that screwed everythign up?
I do wonder what would cause such an issue. You'd think that simple timestamps would catch this issue. I wonder if the original poster changed his clock to match the time for this Ignite conference and that screwed everythign up?
Comparing dates that aren't UTC is a pretty amateur mistake. Comparing timestamps alone is a mistake too.
It doesn't really matter why it broke to be honest, something like that has to be perfect or it's useless. After it breaks for someone it's impossible to trust the system again, negating any benefits. Once bitten twice shy.
They should have done their homework on distributed systems and used something like a vector clock. MS has lots of resources and absolutely no excuse for fucking this up. Especially since small startups have made similar services that actually work.
It doesn't really matter why it broke to be honest, something like that has to be perfect or it's useless. After it breaks for someone it's impossible to trust the system again, negating any benefits. Once bitten twice shy.
They should have done their homework on distributed systems and used something like a vector clock. MS has lots of resources and absolutely no excuse for fucking this up. Especially since small startups have made similar services that actually work.
Re vector clocks, Microsoft even employs Leslie Lamport
He does work at MS, although I don't think vector clocks help here necessarily. I think a strict vector clock implementation _may_ simply tell you that there is no strict ordering in this case, as you had two independent events with no synchronization ocurring between the two (if we take the worst case scenario where they both go online to the service at the same time).
UTC timestamps would solve the issue, unless you lied about your UTC time (hence the time change question).
I must say, unlike the first respondant to my post, while I agree it should never happen -- I think understanding why it did is interesting in of itself. But I'm just one of those people who likes understanding how people make mistakes in software.
UTC timestamps would solve the issue, unless you lied about your UTC time (hence the time change question).
I must say, unlike the first respondant to my post, while I agree it should never happen -- I think understanding why it did is interesting in of itself. But I'm just one of those people who likes understanding how people make mistakes in software.
I don't know enough here to say anything definitively, but I think knowing there's a conflict is half the battle. UTC timestamps are great but clocks have to be perfectly in sync which is unlikely even w/ NTP. And as you mentioned doesn't withstand users changing their system time.
Sometimes bubbling conflict resolution up to the user is a good idea. It's preferable to data loss.
Sometimes bubbling conflict resolution up to the user is a good idea. It's preferable to data loss.
Clocks on both computers are set to auto sync with MS's time server. No clock changes involved. Besides which, everything check-wise should be GMT based no?
[deleted]
I'll send this to the Live Mesh team
>Through the past three years of interminable beta, apparent lack of resources from the Mesh team and/or indifference from management at Microsoft. The complete failure to push forward a product that had huge promise
You're running a business and even after three years of heartbreak you don't have an emergency backup in place?
You're running a business and even after three years of heartbreak you don't have an emergency backup in place?
Ignite is my hobby. My business stuff is all in a VCS which is in turn backed up in duplicate.
And again, in theory Mesh is a backup because it is supposed to duplicate things across multiple machines. The heartbreak wasn't at it not working (in the past), it was at the total lack of apparent support by the powers that be at MS and understanding of what they had on their hands and its strategic importance in keeping the desktop relevant against the tide of 'in the cloud'.
And again, in theory Mesh is a backup because it is supposed to duplicate things across multiple machines. The heartbreak wasn't at it not working (in the past), it was at the total lack of apparent support by the powers that be at MS and understanding of what they had on their hands and its strategic importance in keeping the desktop relevant against the tide of 'in the cloud'.
I'm not a serious IT person, but I imagine a serious IT person would draw a distinction between synchronization systems (like Windows Mesh/Sync, database replication systems, RAID 1, source control systems etc) and true backup systems that create more-or-less non-editable snapshots of the data in question.
Simply because the sync systems can turn against you and amplify your own mistakes, deleting or altering all the copies of something, even when the deletion or alteration was in error. Real backup systems make that sort of mistake much more difficult or even impossible (in the case of write-once media). Certainly, both types of systems can save your bacon, but not in exactly the same situations.
In any case, though, thanks for sharing your experience.
Simply because the sync systems can turn against you and amplify your own mistakes, deleting or altering all the copies of something, even when the deletion or alteration was in error. Real backup systems make that sort of mistake much more difficult or even impossible (in the case of write-once media). Certainly, both types of systems can save your bacon, but not in exactly the same situations.
In any case, though, thanks for sharing your experience.
This is what happens when a PowerPoint presentation is your presentation. PowerPoint should be an aid to a presentation, not the whole shebang.
You should be prepared to give a presentation even if the power goes out and you have to go by candlelight. do not rely on visual aids and make your audience wait if they fail.
You should be prepared to give a presentation even if the power goes out and you have to go by candlelight. do not rely on visual aids and make your audience wait if they fail.
The words duh, and backup both came to mind when reading this article. When I do computer repair, I always carry 2 verified copies of all my softwAre tools on two different mediums. With a file like this, why wouldn't you verify it before the event, and bring the file multiple ways- mesh, email, flash drive and cd?
While I understand something like real backups would have helped this guy, to someone not intimate with the technology, Live Mesh looks like something that replicates your files on many places, something that sounds similar to backups.
I keep my important stuff versioned on subversion, running off a ZFS RAID-Z with weekly snapshots and daily diffs shipped to a different machine on a different site. If something goes wrong with the backups, I get texted in minutes.
I hope to be able to migrate that to BtrFS someday. Will take some work.
I keep my important stuff versioned on subversion, running off a ZFS RAID-Z with weekly snapshots and daily diffs shipped to a different machine on a different site. If something goes wrong with the backups, I get texted in minutes.
I hope to be able to migrate that to BtrFS someday. Will take some work.
Like the article says, backup fails always seem obvious in retrospect. But Mesh has an implied continuous backup component to it. It replicates files, and should do so only in an old->new way. Therefore it is a backup. It isn't as complete as a VCS would be, but should be very sufficient for the intended purpose.
Sounds horrible, for that exact reason I use SugarSync and Live Mesh together to have stuff on multiple platforms. And I email lots of things to gmail: very easy with the drag and drop support in Chrome.
SugarSync is not bad either, 5GB for free compared to Dropbox's 2.
It seriously dislikes my Truecrypted work file. Uploaded it once, won't touch it again, no matter how many changes I make. Emailed support, they said it wasn't uploading because Truecrypt was accessing it, but it ignores it even when it's not running.
Haven't tried it with Dropbox, though; maybe I should.
Haven't tried it with Dropbox, though; maybe I should.