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.
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.
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.
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.
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.
> 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?
Just tried it from the command line and, yes, its quite possible on Windows 8.1.
Windows Explorer (the one in Win8.1, at least) won't allow creation of files with a space at the beginning or end of a name, but it's definitely allowed in the filesystem. For example, from a command prompt, this works:
echo hi > " hello.txt"
Explorer can see this file and perform operations on it, but if you try to rename it to a name with leading or trailing spaces, they get trimmed.
I have used '~' to cause files to sort at the top - this seems to be some oddity of the sorting order that Explorer uses, since ~ would sort at the end in ASCIIbetical order - but at least it's an allowed character at the beginning of a name in Explorer, unlike space.
People might do that, or not... but the fact that someone had to impose these restrictions in the first place, to me, is a warning sign that many places inside the respective software will have parsing issues/issues with handling of "weird" filenames.
In many cases, the restrictions come down to the underlying file-system and how it works. Not saying it is right or wrong, only that the reasons can be very fundamental.
Yes, OS X's Finder still doesn't have a way to sort directories before files. Having the space as first character is just a way to put them to the top.
We have to do that in our database for numbers since zeros get truncated off the left side if it is detected as a number--and the number of zeros is important.
I don't know about people doing stuff in file systems these days like that, but it is a simple hack.
The ways of Microsoft controls can be interesting indeed. At one point, we had to reverse-sort phone numbers to be loaded into a VARCHAR column in SQL Server. The vendor used a Microsoft control, which would look at a couple of phone numbers, say 2025551212, conclude that they were suitable for 32-bit integers, and choke somewhere around the 404 area code.
Then there was the time another package tried to write out street addresses that were something like 3E123 or maybe it was E456. Apparently the control read them as numbers in scientific format that were just way too big.
Since traversing forward is always cheaper than backwards, we subtract our reverse numbers by a magic number for things we want to access in reverse order. Or in this case, dates where the most recent is first.
Yes. Lots of Mac users do it. Goes back to the old 68000 Macs, still works on OS X. True, it's not a great idea if you use the CLI to interact with your computer, but old Macs never had a CLI, and lots of OS X users never open Terminal.
> 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.
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.
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.
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.
"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.
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).
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.
Unfortunately (or fortunately depending on your perspective) Microsoft takes a very "lowest common denominator" approach to backwards compatibility.
A LOT of third party software would definitely be broken if they altered Windows filename restrictions. They would also have to drop support for FAT32 as you pointed out.
Right now a lot of Windows 95 software continues to run 20 years later. And in no small part because of this type of attitude and all the runtime patching Microsoft does.
They did alter the Windows filename restrictions. You can happily create a file that is 1000 characters long, and your Windows 95 software will likely refuse to open it. (Hell, Windows Explorer refuses to deal with it.)
Now we've got a situation where we keep crowing about how changing MAX_PATH would break compatibility. Except, of course, that we already did that by adding the stupid '\\?\' APIs (which are themselves a mess).
So now we don't actually have backward compatibility for those programs (we just make it so hard to use long paths that we virtually have backward compatibility.) And we have file paths that resemble 1995. We don't have the lowest common denominator, we just have the worst of both worlds.
I'm surprised with Metro/Modern/RT/whatever's APIs they didn't try and move forward by utilising \\?\ in Windows.Storage.*. But from what I've been able to tell they have the same limitations as other .Net or Win32 APIs.
> They would also have to drop support for FAT32 as you pointed out.
This is a little dubious. When you load a FAT driver on a *nix system, you get the limitations of FAT. Likewise there are lots of fancy filesystem APIs in Windows that fail on a FAT volume and work on NTFS.
That said, there are a lot of quirky NTFS behaviors that are ultimately rooted in FAT. I used to get frustrated by a lot of them, then I started writing a FAT driver just for fun ... and it made sense. All the goofy things about naming start to make sense if the direntry "is your inode" and the extra space in the name is padded with spaces...
I completely agree. Because of this we ran into all sorts of problems getting FolderShare/Live Mesh/whatever Microsoft calls it these days to sync files between Macs and PCs. I ended up writing a Perl script that would periodically scan the Mac's shared folder for non-ASCII file names and normalize them by brute force. It was ugly. I told my boss that if it broke, he got to keep both pieces.
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).
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.
As bad as these behaviors are, I think the delete behaviors (specifically STATUS_DELETE_PENDING at the NT layer) are worse. Deleting a file reserves the name until the last handle is closed. "Delete file, re-create file with same name" is a very dangerous pattern on Windows.
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.
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.
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.
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.
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).
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.