Sharepoint has its origins in managing collections of MS Office documents more so than HTML and browsers. It knows about certain document types and tries to do intelligent things with them. It's not necessarily the tool you would use for serving raw data over HTTP with arbitrary Content-Types. (Given the complex and varied rules by which browsers interpret content, I'm not actually sure how one could even do that perfectly securely short of enforcing separate second level domain names for each and every tenant.)
As an old-school software engineer, we used to say the biggest part of requirements analysis is setting customer expectations correctly. It seems fair to say that the renaming of Sharepoint to "OneDrive for Business" has surprised some folks where it behaves differently from plain OneDrive or from raw BLOB store.
There's your problem right there ....
Please name three nontrivial, commercial, end-user facing apps or services that know nothing about any file or document types.
The only problem is that we are talking exactly about a file synchronization tool. Thus the exercise isn't as valuable as it may appear at first.
The stand-alone OneDrive for Business (formerly SkyDrive Pro) sync client lets users of Microsoft SharePoint 2013 and Microsoft SharePoint Online in Office 365 sync their personal OneDrive for Business (formerly SkyDrive Pro) document library or any SharePoint 2013 or Office 365 team site library to their local computer. This sync relationship provides access to important content both online and offline. The OneDrive for Business (formerly SkyDrive Pro) client can be installed side-by-side with previous versions of Office (such as Microsoft Office 2010 and Microsoft 2007 Office).
I tried the installer. The installation process is branded all over as being a feature of Office.
Is there something other than the substring 'Drive' that gives the expectation of a fully generic file synchronization tool?
I don't think anyone is expecting OneDrive to be "fully generic" (I believe that 'emeraldd was referring to the "tries to do intelligent things" portion of the sentence he quoted).
It just seems that people are unaware of the fact that putting certain kinds of documents into "document libraries" or "team site libraries" involves automatically adding metadata to those documents (from the OP's example, html comments and "xmlns:..." attributes were added to html files).
Sigh.
More correctly "Surface RT" vs "Surface Pro". "Surface" was initially Microsoft's interactive table [1], so yeah pretty much a branding disaster if we take a walk down the history lane.
[1] http://en.wikipedia.org/wiki/Microsoft_PixelSense#Microsoft_...
Btw, I just noticed that the old Surface is now known as PixelSense. Makes sense.
MSFT (and other companies) have a very bad habit of circular/redundant/superfluous naming conventions.
In this case Pixelsense and the renamed Surface RT never had direct naming overlap.
I think the idea was to have "one" device (even though there were actually two different devices, with very different hardware) with the name of Surface, but which came in two versions, one with Windows RT, and one with Windows 8 Pro. So they were telling people: "This is Surface with Windows RT...and this is Surface with Windows 8 Pro".
But yeah, a disaster. Their current names of Surface and Surface Pro may be simpler to use now, but it's actually more confusing for consumers, because this current naming implies Surface Pro is basically Surface, but with a few extra features. When in reality, they are very different. I think this confusion was meant on purpose, because they want people to believe that Windows RT is "just like regular Windows - but with fewer features". They are doing their customers a disservice by trying to trick them like this.
Namely, AirPlay between OS X devices and iOS devices (including just audio and both audio+video), in either direction. Here's hoping for OS X 10.10.
Wonder if it would modify files in a git repository in the same way? Good luck recovering from that!
I would recommend that everyone keep working copy of their source code outside of any form of syncing. If you must, create tape archives (or 7z or something) and sync them but never your working copy.
As many others have said, OneDrive For Business is really more of a SharePoint + Groove document sharing / collaboration thing for businesses documents (as the name kind of implies). While it does similar things from a generic corporate user point of view, the mechanics are pretty different. OneDrive For Business works well for the same kinds of use cases that SharePoint does (mostly documents), but I wouldn't put source code in there.
Let me put it this way: I would be scared to store an svn checkout because of how svn stores metadata copies. I wouldn't worry about a git checkout.
IIRC the Office Org owns the SharePoint client while OneDrive proper is handled by the Windows Services team.