OneDrive users around the world have been upset to discover that with its latest update, Microsoft’s cloud file syncing and storage system no longer works with anything other than disks formatted with the NTFS file system. Both older file systems, such as FAT32 and exFAT, and newer ones, such as ReFS, will now provoke an error message when OneDrive starts up.
While it’s understandable that FAT-based filesystems are left behind – FAT needs to die a quick but horrible death – it seems weird that Microsoft’s new ReFS isn’t supported.
FAT is still the only file system supported out of the box by a multitude of operating systems. It’s not going away anytime soon.
You got that right. Until these moronic companies can decide to actually work together to come up with something compatible out of the box which is better than FAT and doesn’t cost a fortune in licensing, we’re going to be stuck with the lowest common denominator in filesystems for a long time to come. Idiots.
It’s not so much morons as cheap-skates. Very few modern filesystems can be implemented on an 8-bit embedded processor with maybe 16KB of ram. Until one comes along, you’re stuck with one that can, and FAT is that filesystem. Well, that or you get rid of all cheap low-end embedded processors with tiny amounts of ram.
We already have many replacements, for example ext{2,3,4}. It’s better, it’s free, no licensing issues. They just don’t want to do it.
The only company who won’t agree to something else is Microsoft, because it wouldn’t be something MS has a stranglehold over the licensing rights.
A lot of new hardware for retro computers (floppy emulators, IDE adapters, etc) depend on FAT file system being supported, as it is one of easiest to implement for micro controllers, enabling data exchange between that hardware and PC.
FAT can survive just fine for those use cases. However, we shouldn’t be using it in damn new, modern, up-to-date hardware.
I doubt new computers are the issue. I know a good many people who sync their cloud drives to an external storage medium, often formatted as ExFAT or FAT32 for compatibility between many machines. They essentially use the cloud service as an off-site backup for their external drive (kind of odd, but it works for them I guess). It’s these people who are likely to be most affected, though none of the ones I know personally are using OneDrive so it won’t bother them one bit.
Exactly. FAT is still the only one that can provide true cross-platform “portability”. There’s just no other file system that you could use across all the major OSes with no issues.
One Drive really means OneFS, that is NTFS.
Office 365 I believe is now down to Office 337 and could go lower.
Microsoft Azure sites are often down more than up.
Keep up the good work Microsoft!
What? You don’t need Azure access if you’re using Office 365 unless you’re using the online Exchange and OneDrive (really SharePoint) features. Otherwise, it’s fine. I use my Office 365 subscriptions just fine regardless of Azure status.
Cloud much?
I am not understanding something here. Ignoring the fact that FAT is awesome and anyone who says elseways is an obtuse potato licker, Fat and other files systems were working.
Microsoft just killed them off for no good reason. One drive is kinda of a service that could theoretically earn microsoft money. Wouldn’t they want to get as much usage as possible? What gives?
There is either a really good technical answer as to why they disabled it. Or its crazy MS doing stupid stuff because management said “only NTFS!”.
FAT also doesn’t support permissions, ACLs, etc like NTFS does. So it’s no surprise that something like O365 which probably uses a lot of metadata capabilities in NTFS, ACLs, etc to enforce things and track information is not compatible with FAT.
Now, ReFS should have those things – or at least one would hope they do. I don’t know the details of ReFS so it might not.
All true, but how many other file systems can you read just via raw hex?
Hmm, like all of them? I don’t see how FAT is any different in this regard.
I also don’t see why would anyone except a very highly specialized engineers would want to do that.
Edited 2017-07-10 07:32 UTC
Umm, quite a few are not all that difficult to work with in that context. ext2, 4.4BSD’s UFS, UDF, ISO 9660, and the MINIX 3 filesystem are simple enough I can do so with little more than the structure definitions for the Linux drivers for them. I’ve also done so (with notes and full documentation) with most ‘modern’ filesystems except ZFS, including multi-device BTRFS volumes.
Keep in mind also that that degree of simplicity is just as much of an issue as it is a good thing. Yes you can fix a FAT filesystem by hand if it gets broken by a crash, but for stuff like ext4 or XFS< it usually won’t be broken to that point to begin with.
Reparse points.
Remember how OneDrive for Windows 8 had placeholders that let applications access files that weren’t stored locally, as if they were stored locally?
Microsoft nuked that feature, in part because it wasn’t reliable – there were lots of situations where it didn’t work.
Microsoft is bringing back this feature, only they’re doing a lot of low-level work to make it more reliable. Reparse Points in NTFS are a part of this.
For example, previously it didn’t work with command line programs, or 16-bit Windows apps. There were other situations, too.
Microsoft is fixing this by doing a ton of low-level work, so even command line programs and 16-bit Windows apps should work (Provided you’re on 32-bit versions of Windows 10, that is).
ReFS also supports reparse points, so ReFS should work. Why they don’t support it is a mystery at this point, but maybe the low-level work they’re doing is NTFS-specific.
Ok, that kind of makes sense. New features( major improvements) that only work with NTFS features.
Drumhellar,
The complexity with foreign file systems through the 16bit interface is that it uses 8.3 filenames, so every long file name needs to be assigned a short persistent abbreviation. With FAT32 and NTFS this is trivial since both of these file systems inherited short file names as part of their backwards compatible evolution.
Consider:
1) The algorithm needs to take care that long file names don’t map into the same short file name.
FAT and NTFS handle this using the familiar “C:\PROGRA~1” numbering algorithm.
2) The short file name should be persistent over the file’s lifetime.
FAT and NTFS handle this by saving the short file name.
You might take any arbitrary file system and generate short filenames that comply with #1, but it’s impossible to comply with #2 without a stateful mechanism or database.
Consider what happens if we have these three files:
My resume A.doc -> MYRESU~1.DOC 2015
My resume B.doc -> MYRESU~2.DOC 2016
My resume C.doc -> MYRESU~3.DOC 2017
If I delete “My resume A.doc” at the network source, without a stateful mapping there’s no way to know what the previous short filenames were and it creates a race condition where a 16bit client may try to access or even delete the wrong file.
This is all just a historical footnote though, none of this affects 32bit programs from win95+. Besides, my 16bit programs have not worked since windows XP anyways, haha. Once and a while I will mess around in dosbox
Edited 2017-07-07 20:45 UTC
Does OneDrive maintain 8.3 filename compatibility? I wonder if this is why OneDrive isn’t supported on ReFS, since ReFS doesn’t support 8.3 names.
Drumhellar,
Are you positive about that? Normally file systems should be handled inside the kernel rather than by intercepting win32 calls…unless it was just an explorer extension? I have seen that (mounting my phone for example). In that case, yeah some programs see the files while others do not. Real kernel drivers do not have this limitation though.
While I don’t use onedrive, it seems excessive to disable itself completely for FAT32 partitions, why not support those disks with the NTFS features disabled? This seems like the more logical solution to me.
You’re right. It was handled by Explorer, and the OneDrive client, not by API hooks.
Opening files in Explorer, or via the Open/Save dialog, opened the files correctly – it’d download the file and replace the stub in the filesystem before passing it to the program. However, using the Win32 API call directly wouldn’t work properly – it’d either wouldn’t find the file, or open the empty stub file, depending on how the call was made.
No, FAT is not “awesome”. It’s an awful, horrible file system to use in 2017 — no journaling, no ACL, no compression, no encryption, does not scale well at all, has really pressing limitations such as 4GB max. file size, and even max. partition size is already becoming an issue.
The only reason why FAT must live on is for cross-platform and cross-device compatibility…
ExFAT, on the other hand, is quite an OK alternative (though also not great), but it’s still far from being as universal in terms of compatibility as FAT32 is.
Good riddance one drive! After years looking for a solution to block that malware.
Now, how I can get w7/8/10 to get installed on fat32 (or fat16)?
More seriously, I need to know how to install “office’16 H&B” w/o that malware. (I haven’t researched it, yet)
Malware? Really? That’s a bit of hyperbole, don’t you think?
Not really. When you have to fight some piece software, try hard to force it to get out of your way and let you use your computer the way you want, it’s quite appropriate to call that piece of software a malware.
You are confusing OneDrive and OneDrive for Business, which is logical because Microsoft really made a mess of that naming when they replaced OneDrive for Business and OneDrive with “the new OneDrive Sync Client” that they called Onedrive.
Actually trust MS with their data anyhow? Onedrive was one of the first things I disabled when installing Windows 10.
Still works fine on HFS+ on macOS. Let’s see what happens after APFS gets traction.
because it is the only filesystem which can be handled by MCUs with only a few K of RAM.
No way to support NTFS, ext4 or anything like this in small and tiny embedded devices.
And of course, desktop computers also _must_ support FAT in the future to exchange media between those devices and PCs (including Windows, MacOS and *nix)
DeepThought,
Yea, that’s the main thing, because microsoft’s monopoly won’t support 3rd party file systems in windows, vendors have to support FAT anyways, so the viability of alternatives is largely mute.
Embedded devices are much more then cameras or mobile devices. I am not talking about devices with megabytes of RAM, but only a few Kbytes like Cortex-M0 based ones. As you found, FAT filesytems can go down to sizeof(sector) plus a few bytes for handling the filesystem.
Edited 2017-07-09 15:22 UTC
DeepThought,
Yea but most embedded devices running on MCUs don’t have user accessible partitions either. In general it seems embeded devices with user media generally seem to run an OS such as Linux (like the cameras and mobile devices), and at that point alternative filesystems aren’t very far fetched. My NAS box is an example of an embeded device running linux and it can access EXT2/3 and XFS. Even my printer runs linux.
I don’t think it’s typical for MCU applications to have user accessible storage. Of course it’s not a hard & fast rule, but I was just wondering if we could come up with specific counter-examples?
Edited 2017-07-09 17:02 UTC
I earn my living writing RTOS and middleware for embedded devices. And there are a lot of them which use either SD card or USB sticks to exchange data or to update the firmware. (For example: https://www.endress.com/de/messgeraete-fuer-die-prozesstechnik/Syste…)
Maybe not all these devices offer access for the common user, at least for the service technicians they do.
Again, still 90% of the embedded devices do not and cannot run Linux. Even some of our customer could do so because of the power of the MCU and the big enough RAM, they don’t … (But that’s another thread…)
DeepThought,
Well, it’s not a big deal, but the reason I asked for specific examples of embedded devices that can’t run an OS such as linux yet do offer user storage is because I can’t think of any, at least not in my house.
Plenty of things potentially use micro controllers: microwaves, remote controls, fridges, clocks, speedometers, calculators, thermostats (although mine actually runs linux), etc. But I personally can’t think of any that have accessible file systems.
I’m also curious how many embedded devices could be using a home grown file system. The embedded projects I’ve worked on were usually so specialized they just used hard coded structures and didn’t require a file system at all, this is probably the majority of micro-controller usage. We handled field updates with a bootloader that reprogrammed the PROM and we used a simple binary image rather than file system. In my experience this seems to be a common way to update embedded linux devices as well.
Edited 2017-07-10 02:47 UTC
EFI boot partition is FAT32. So we are stuck with it for quite some time.
We need a cross OS support file system that does not have a stack of patent demands on it. That is particularly hard thinking the Mirosoft only support file systems they create and those are always patent locked up. So 20+ after Microsoft release file system.
So exfat is like 2026. So at least another 10 more years of FAT32.
“FAT needs to die a quick but horrible death”
I ask you, what file system are you using for the SD card in your Andoid phone?
When I tested exFAT with ~40GB of small files on Android 6.01 it fell on its face. The system “Media Storage” process wouldn’t finish cataloging the whole volume and apps which had data on the card wouldn’t work.
Reformatted the same card to FAT32, copied the same data and had no problems.
That was a year ago, maybe they fixed it but even if they have, 95% or so of handsets in the wild will have this limitation.
FAT32 serves many purposes very reliably and is sometimes the only viable option. The 4GB file size limit is often not a problem and the lack of permissions and indexing can be a positive for performance if you don’t need them.
Edited 2017-07-09 02:03 UTC
I run only NTFS on my Win10Pro system. However, I use a symbolic link to transparently have my user directory on a different drive. For the last few weeks, OneDrive is failing to install as well.
I am not getting any specific errors such as a formatting demand, just general failures to install/update to the latest version. Every attempt fails silently.
And what exactly is your suggestion for FAT replacement on all those millions of devices that ONLY support FAT? Also, which other file system is fully supported across multiple platforms such as Windows/Mac/Linux?
Oh wait, was this yet another signature Thom comment that actually makes no sense and is there only because someone feels the need to “make a statement” and “express his important opinion”?
Linuxers never believed that much -on clouds- that is.
OneDrive had relied on the “offline” file attribute since the beginning of its existence as SkyDrive. It piggy-backed on the old “Windows Briefcase” feature which, along with sometimes-online shared drives, pioneered the use of this file attribute. On FAT filesystems it is present but for whatever reason Microsoft feels it is no longer suitable on FAT.
DropBox didn’t use this attribute in the beginning and I believe only in the past few years started using it. I remember logging into new machines and starting DropBox and getting everything downloaded at once. OneDrive/SkyDrive never did that on NTFS volumes which made it a better solution.
Without this attribute, a huge, local cache must be maintained much larger than would otherwise be necessary if this attribute were present.
However, the best solutions are the few online storage solutions that represent the online volume as a real Windows disk drive. pCloud.com is the only major commercial provider that presents a true disk drive to Windows and handles all the synchronization and updates under the covers. The library they use is sold by EldoS.com and is very robust. You can even back up large, encrypted volume containers and even databases using pCloud and its EldoS driver.