30

I have a laptop with dual-boot Windows 10 and Linux Mint 19 Tara installed to the internal M.2 SSD. Apart from all the OS-specific partitions, I have a 4 GB FAT32 partition on that SSD that I intended to use for copying files between OSes.

The problem is, that after changing anything minor on that partition (create a small text file/any folder, edit one, etc...) in Linux and afterwards booting Windows, Windows doesn't see any changes to the partition. So when accessing it, the "invisible" data gets corrupted and lost (permanently, to both OSes). This usually doesn't happen when I copy a large file to it, then all changes are visible in Windows as well. Also Windows always shows the partition as empty, despite files created in Windows being present.

I'm assuming either Linux is not committing changes to disk, Windows is caching the partition or the FAT-Table somewhere or the drive does some weird caching.

The question: How do make Windows agree with changes made in/by Linux to that partition?

For clarification: by "invisible" I mean according to Windows actually not there. And the opposite direction works perfectly fine, changes made by Windows get picked up by Linux no problem.

Skipper
  • 103
  • 4
Poohl
  • 403
  • 4
  • 5
  • 2
    Possible duplicate of [Shutdown Windows 10 truly for a dual booting system](https://superuser.com/questions/1152001/shutdown-windows-10-truly-for-a-dual-booting-system) – Run5k May 16 '19 at 13:28
  • Just for information you can also use ExFat as a cross operating system file system with less restriction than FAT32 (also compatible with MacOs) – JFL May 16 '19 at 18:57
  • note that Linux can read/write NTFS and exFAT without problem. Why use FAT32 which is prone to errors? – phuclv May 17 '19 at 01:47
  • 1
    @Run5k The solution is the same, but the question you suggest is essentially "Where can i change this OS-Setting?" whereas my question is "What needs to be done, to fix a thing?". Whoever asked your suggested question already knew what caused the issue, anyone who doesn't will never find your suggested answer. – Poohl May 20 '19 at 12:50
  • I understand what you're saying, but ultimately the *root cause* of the problem is essentially the same. Potentially, the Super User community could post a question with a dozen different scenarios that are only somewhat similar, but the root cause behind the problem is the most important aspect to emphasize. – Run5k May 20 '19 at 14:49

3 Answers3

44

It may be that, when you boot Linux, you have left Windows in a sleep/hibernate state rather than shut it down.  (Windows 10 is notoriously resistant to being shut down properly.)  Windows may be keeping part of the filesystem cached in memory (i.e., the page file) and does not expect some other operating system to have modified the disk.

Try to figure out how to really shut down Windows.

  • 7
    Thanks, that seems to be it. For anyone in The Future: reboot or shift+klick on the shutdown button _really_ shuts windows down. Alternatively you can disable this behaviour in the Controlpanel->...->Define power buttons->untick Fastboot. – Poohl May 16 '19 at 07:49
  • 10
    *Windows 10 is notoriously resistant to being shut down properly*... That's a bit misleading. The issue is not an improper shutdown, but that Windows *by design* performs a hybrid shutdown. The fact this has consequences in a dual boot scenario doesn't merit describing the feature as "improper." – I say Reinstate Monica May 16 '19 at 09:18
  • 61
    @TwistyImpersonator: I think most users of other OSes would agree that when the menu entry marked "shutdown" does not in fact simply shut down, but rather suspends to disk, that's easily confusing and could be considered misleading. Especially if you're used to Linux where "shutdown" does have a specific technical meaning that doesn't include sleep/suspend, but you're right that user expectation based on other OSes is arguably not Window's fault / problem. Anyway, this answer isn't saying it's "improper", just that Windows doesn't clearly distinguish different kinds of shutdown for the user. – Peter Cordes May 16 '19 at 09:55
  • 1
    For further reference on what Hybrid Boot is, [there's an earlier answer here](https://superuser.com/questions/491150/what-does-a-hybrid-boot-do-and-why-wouldnt-i-always-enable-it) that explains it in a succinct way (about Windows 8, but still applies) – user10186512 May 16 '19 at 10:38
  • 2
    @PeterCordes Windows is aimed at the average user who doesn't do much more than use Office software on their corporate machine. For those users, every minute their machine takes to do things is lost money for the company. And your average data entry clerk isn't going to have 2 operating systems on their computer. For those people, who are still the large majority of Windows users, potential issues with something that's not even on their machine is about as relevant a problem as a farmer in Kenya not finding one of his cows. – Nzall May 16 '19 at 12:00
  • 6
    @Nzall - what is your point? Obviously defaulting to a hybrid shutdown that can resume quickly is a good design decision (now that Windows is generally robust enough not to need frequent reboots because of memory leaks or whatever), and so is reducing cognitive load for typical users. That doesn't mean it's not confusing for cases where the distinction does matter. Perhaps labeling the option "power off" without calling it "shutdown" would help (talking about physical power state, not OS software state), but probably not really because people will still assume it means shutdown. – Peter Cordes May 16 '19 at 12:07
  • 3
    @PeterCordes My point is that Microsoft is well within their rights to change the implementation and side effects of a certain Windows feature without changing the outward appearance if the outcome of the change is a net improvement for the average user. multi-boot environments are only a tiny minority of computer users, and those that do use such an environment are without exception more technical users who know how to fix any issues they encounter in such an environment. You don't avoid improving something for 95% of your users because you might cause issues for the remaining 5%. – Nzall May 16 '19 at 12:48
  • 4
    @Nzall: None of the things you're arguing against are claims I've made. Like I already said, this is a good design decision by MS. (Which people need to be aware of for the rare cases where it matters.) – Peter Cordes May 16 '19 at 12:50
  • 30
    And the winner of this year's contest of counter-intuitive UI behaviour is once more ... Microsoft! – rexkogitans May 16 '19 at 14:53
  • @Poohl Most linux based oxes actually warn you about this when you try to access the partition, what linux OS do you use? – Ferrybig May 17 '19 at 08:44
  • 1
    That's some appalling lack of concept on the FAT and hybrid shutdown authors' part. Something as simple as flushing writes before hybernation and writing a new ID to a designated area in the partition on every write mount could have fixed this. Then discard the read cache if the ID changed, of course. Moreover, if the system partition ID changed, discarding the hibernation data should become the default action to prevent data corruption. – Zdenek May 17 '19 at 16:50
3

Recent windows versions do include startup optimizations that involve caching disk data somewhere different than that same disk, which causes the behavior that you found when the disk is accessed by a different OS.

You can use the Group Policy Turn Off Boot And Resume Optimizations (located in Computer Configuration\Administrative Templates\System\Disk NV Cache) which should make Windows only store the files that on their partition. There are also some other Nonvolatile Caching settings available, but that one should fix your issue.

Ángel
  • 1,218
  • 1
  • 8
  • 11
0

To complement the previous answers and add some extra information:

The problem also happens on Windows 11*, and it's not limited to FAT32 partitions or even to the partitions being on the same Drive. Apparently Windows does this to all the internal drives it can access (I tested it with FAT32 and exFAT partitions on both the same SSD as Windows itself and different internal drives).

For Windows 11, disabling Fast Startup seems to have solved it. (Files I created in linux were visible in Win11 and weren't overwritten when I created new ones there)

Other caching options seem to only apply to external drives and don't really solve the problem for internal drives (an SSD and an HDD in my case), but if that's the case, the other answers to this question cover that.

The answers for this question might be applicable for Windows 10, too (the interface is slightly different, but it's literally the same setting).

* Funnily enough, with Fast Startup on, Windows 11 didn't seem to notice even drastic changes, such as reformatting the whole drive and changing its partition table. I didn't dare test what it'd do if it tried to write to the drive in that state.

Mel O.
  • 1
  • 1