

C:\ONGRTLNS.W95, OneDrive - smcgivern
http://ignorethecode.net/blog/2014/11/05/onedrive/

======
Someone1234
I can totally relate to how insanely screwed up Microsoft accounts are,
particularly when it comes to regions.

I purchased a Surface 3. Later on I decided to add their warranty ("Microsoft
Complete") due to concerns about heat levels on the i5 S3.

So I went to their warranty page, entered all my info, and nothing. It stopped
me on the shopping cart page with the warranty in my basket, no error. Just
refuses to continue.

After spinning up the developer bar and looking at the network tab I was able
to discern that an error was being returned but it was just a generic internal
code with no description or Google-able resources.

I talked with support, they couldn't help me, and just suggested I email a
different support email address who never got back to me (even now).

After a couple of weeks I had all but given up on ordering the warranty. But
after having activated Google Authenticator on my Google Account, I decided to
poke around in my Microsoft Account settings to see what they offered
security-wise, and noticed my "basic info" region was set to the UK (I am in
the US currently), even though my billing info was set to the US...

After changing my "basic info" region the warranty site just worked correctly
as you'd expect. Not that I ever would have known that had it not been for
pure luck.

~~~
cridenour
You might try a different browser. When I used Chrome, no matter what I tried
I couldn't sign up for Office 365 for Small Business. With strange errors
about fields not on the page.

When I switched to Firefox, it magically worked.

~~~
Someone1234
One of the first things I tried was using it in IE.

------
thefreeman
Not detracting from any of the points of the author, but this line caught my
eye:

 _For example, you can’t start files with a space, something a lot of people
do to move files to the top of alphabetical lists._

Do people really do that? That would drive me bonkers. Granted, I mainly work
from a CLI so I guess it may not be as annoying if you mainly use a GUI.

~~~
w8rbt
Mac OS9 users created filenames with spaces at the front. They did this for
years. Their goal was file sorting. When they wanted a file to sort higher, I
believe they simply added more spaces. I've never seen any other computer
users do that.

And also, I did not realize that you could create filenames that contained
spaces at the front (or back) on Windows systems. In fact, I'm not sure that's
ever been allowed on Windows... has it?

About 15 years ago, I had to migrate an entire Mac OS9 office group (200
systems) to Windows PC. I wrote a Python script to validate filenames and fix
them in cases where they contained illegal Windows characters. We would ftp
the files up to a Unix system, run the Python filename cleaning script then
ftp down to the Windows PCs. It worked rather well, except for cases where the
accountants named files something like this, "Summer-Report-07/15/1997.csv"

Mac OS9 file names allowed many characters that Windows did not and OSX may
have inherited some or all of these things.

~~~
cesarb
Unix tends to be ridiculously permissive with allowed characters in file
names. On Linux, the only disallowed characters are NUL and the slash, and
they are only disallowed because they have a special meaning (string
terminator and path separator).

AFAIK, MacOS X also disallows NUL and slash, but IIRC its GUI silently
switches slash (Unix path separator) with colon (which IIRC was the MacOS 9
path separator). So, if you were to migrate to OS X instead of to Windows (and
if my knowledge is correct) you'd just have to replace the / with a : and the
users wouldn't even notice.

~~~
0942v8653
Yes. That was for compatibility with os 9—when you copied files over they
wanted the names to stay the same so they just switched the / to a : and back
again.

------
pavel_lishin
> _To add insult to injury, every time OneDrive encounters a file whose path
> is too long, it just shuts itself down and completely erases all of its
> settings._

I have no idea how this was missed in QA.

~~~
acchow
Possibly because Windows has a 255-character limit per pathname component; HFS
doesn't. I suppose unit tests for some encoding internals are shared between
the two clients.

~~~
xenophonf
The Windows API has a nominal 260-character pathname limit, including the
leading drive letter designator (e.g., "c:\") and the trailing NULL, but the
Unicode versions of the various file system APIs have different limits, as
does NTFS internally. The limit to which you're referring is actually a
maximum NTFS filename (pathname component, as you said) length limit of 255
UTF-16 code points, which is also the maximum size of an HFS+ filename.

~~~
Someone
There are issues other than component length.

HFS+ happily stores characters in paths that NTFS does not accept such as |
and $ (and, I think to this day, /. Traditional Mac OS used colons as path
separators. The Mac OS X Unix layer swapped colons and slashes)

Also, NTFS and HFS+ use different Unicode normalization algorithms (IIRC, the
Mac decomposes strings; that would make Mac paths longer in some cases)

If you look closely, it is a miracle that we can have interop between
different file systems at all. There is a lot of ugliness here. For example,
see what Microsoft says about that 255 character limit:

 _" The Windows API has many functions that also have Unicode versions to
permit an extended-length path for a maximum total path length of 32,767
characters. This type of path is composed of components separated by
backslashes, each up to the value returned in the lpMaximumComponentLength
parameter of the GetVolumeInformation function (_this value is commonly 255
characters*)."

So, before starting that copy, you really should query the target disk for its
maximum pathname component length.

Finding hat disk in the presence of reparse points, substituted drives, etc.
may be a challenge in itself.

------
peterkelly
"Just for fun, I tried to buy another Office subscription, but this time, the
Euro store informed me that I can’t buy an Office subscription, because I’m in
the store for the wrong region"

After reading the recent "Bullshit jobs" article, I wonder how much human
effort has been expended on deliberately making it harder for someone who
happens to be in one country to buy from a company that happens to be in
another.

------
hadoukenio
PSA: Don't use OneDrive if you value your privacy:

    
    
      http://cryptome.org/2014/11/ms-onedrive-nsa-prism.htm

------
xenophonf
These problems with path names on the Mac have been an issue ever since
FolderShare was originally ported to Mac OS X. Those limits are straight out
of the Windows API ([http://msdn.microsoft.com/en-
us/library/aa365247.aspx](http://msdn.microsoft.com/en-
us/library/aa365247.aspx)).

~~~
asveikau
You can bypass most of these limitations on Windows by prefixing your path
with \\\?\\. Suddenly instead of 260 chars you get 32k if memory serves. And
trailing dots and spaces (at the end of a file or before its extension --
limits that come straight out of FAT's direntry structure) are OK.

So really I'd say these are limits of not knowing or bothering to use the
escape hatch in Windows's support for this stuff.

~~~
AlyssaRowan
Oh, yes, _those_. Please be advised that they are possibly one of the ugliest
bits of the Windows API. You could blog about this nightmare.

Particular hairballs to watch out for regarding the path length/filename
length issue (please forgive me if I've got these slightly wrong as I'm
paraphrasing roughly from memory):

• Normal MAX_PATH == 260 WCHARs (hardcoded in the Windows API), including the
drive letter, colon, backslash, _and_ the trailing NUL;

• Directory names in the normal API can't be longer than (MAX_PATH-12) WCHARs,
so that they can always contain a FILENAME.EXT;

• You can use extended-length paths with a "\\\?\" prefix (exactly); UNC
network drive paths which you want to be extended-length should start
"\\\?\UNC\" (exactly), then append the server name, backslash, share name,
backslash, path and file etc;

• Extended-length paths only _generally_ work with W/Ex APIs;

• The _buffer_ used for extended-length paths is 65536 bytes, including the
trailing NUL, but that also needs to contain any expansions during processing;

• Names passed with the extended-length API do not have to be valid or
normalised Unicode;

• Components (split between backslashes, i.e. filenames) of an extended-length
path are in fact still limited to
GetVolumeInformation/GetVolumeInformationByHandleW/etc's
_lpMaximumComponentLength_ , which is often 255 (WCHARs) _but not always_ ;

• It counts WCHARs not codepoints (look out for codepoints beyond the Basic
Multilingual Plane!);

• There are no relative paths or current directories in this API, everything
is absolute, so no plain filenames, and "." and ".." are actually valid names
not directory references;

• Most of the Explorer shell, and all of cmd.exe (as of W8, don't know about
W10) doesn't use them, and because of the above you can't use them as a _cd_ ,
you can pushd them but stuff will break;

• Several APIs don't even support it;

• So you can make files and directories which a good half of Windows and
related applications can't do anything with, and are very pesky to delete…

…and beyond that is where it gets _really_ hairy. The code in this area
involving devices (from "\\\\.\PhysicalDisk0" to good ol' "COM1") is
particularly Cthulhu-esque, as is the code regarding Terminal Services and
Hyper-V. (A good sweep through there looking for off-by-ones might be
fruitful, as those with sharp eyes may have spotted from the above.)

I'll make allowances for needing to be incredibly careful about backwards
compatibility to a really old VMS/GEMDOSish codebase, and being patch-upon-
patch-upon-patch as a result. But that they had the opportunity to fix it in
NT, and sadly missed it irks me: that and the locking semantics (especially
regarding running executables) are probably my least favourite characteristics
of Windows.

Linux, for example, is much easier about this particular kind of thing, but
its flexibility does have its own problems when absolutely _anything_ can be
in a filename and people often forget that (for example, the delightful fun
that can ensue when someone starts a filename with "-", say, "-rf" and someone
does a "rm _" which globs it first, because globbing doesn't know or care what
switches are, but _you* will).

~~~
cesarb
And AFAIK you can't have a file named "aux.c" (which would be a perfectly
legitimate file name otherwise). That's the one which has the most probability
of tripping developers using saner systems: create a file for your auxiliary
functions, commit it to the repository, and congratulations, you just broke
things on Windows.

------
cbhl
The Author should really consider contacting Microsoft Support, especially if
they're a paying Office 365 customer. When I moved from Canada to the US; I
had to go through about two or three reps but managed to get everything sorted
out after about an hour or two. Much nicer than what Google made me do:
abandon my old GMail account and create a new one.

~~~
LukasMathis
Yeah, I didn't put down the whole story in the article. I actually did talk to
support at some point (there's no email address, so I _had_ to call them). The
first-level support rep wasn't able to help me, and I spent so much time
talking to that person that I simply didn't have the time to start fresh with
somebody else. Maybe I'll try again when I have a day off.

~~~
cbhl
Strange. In the US, you can get tech support over live chat. When one session
wasn't bearing fruit, I opened another chat session to get another CSR at the
same time and the second CSR managed to figure it out.

------
mzr
I've been using OneDrive on multiple Macs and have not encountered the pegged
CPU. It seems to be a bit better than the Windows client, which takes ages to
transfer a file to the local drive.

------
ahassan
Why not just use Dropbox? It's always been extremely reliable for me on my
Mac.

~~~
Someone1234
That is stated in the article.

They're already paying for Office 365 so SHOULD be entitled to "unlimited"
OneDrive storage. It just doesn't work (either the unlimited or OneDrive in
general).

~~~
bambax
Something that's "free" but doesn't work isn't free, it's a waste of time.
What's the point of being "entitled" to broken??

~~~
Someone1234
I didn't use the term free and there is no point.

------
kyberias
TIL that people use whitespaces in the beginning of filenames to order them.

