Hacker News Reader

While technically hibernate (to disk at least) should unmount all filesystems - I'd be very wary of using hibernate (on either os) in a dualboot setup.

Other than that - my experience of late has been that ntfs is safe both to read and write from linux -- but as I now encrypt all my filesystems, that doesn't really help (no bitlocker support). If I actually needed to dualboot -- I suppose a separate disk/partition with truecrypt might do the trick.

My solution for the past several years have been to have all "interesting" files on a separate linux file server -- and access it with cifs/samba and/or ssh.

> While technically hibernate (to disk at least) should unmount all filesystems

Not a chance. Hibernate is just like Suspend to RAM: freeze all processes but core kernel, blit RAM to disk (usually stored in swap) and send poweroff command straight to CPU. Of course it doesn't unmount anything, hence there are FS data structures live in RAM. Booting an alternate system and accessing a filesystem open on the other side is like mounting twice the same filesystem and writing to it. It will blow up on you.

Ah, I was thinking of the Debian package for hibernate, that has custom scripts for unmounting selected file systems, from the help text:

  "If you have network shares or external devices that should be unmounted before suspending, list them here."
  "Unmounts any filesystems of the given types. This is most useful for network filesystems such as smbfs and nfs."

And afaik it is perfectly possible to add ntfs mounts to that list - but I don't think any program with open files on that mount would handle it gracefully (I belive the script will figure out which processes (if any) have open files and kill them prior to hibernation).

You can't change Windows code to 'add ntfs mounts to that list'.

Windows 8 will in fact do hibernation when you think you have turned off the computer.

Bottom line: You can't dual boot safely with Windows 8.

Yeah this bit me recently, as I was hibernating my linux system but sometimes booting into Win7. Ended up having to reformat linux partitions, some inode information got messed up. e2fsck found and 'corrected' some errors which really didn't help at all. Lesson learned, as long as I'm dual booting, will stick with s2ram!

You can suspend-to-disk just fine, as long as you remember to always boot back into the OS you suspended from. I guess suspend-to-ram forces you to do that (and my preferred option anyway), but I just wanted to make sure it was clear that there's nothing unsafe about suspend-to-disk as long as you don't let another OS get its grubby fingers on your mounted disk.

Linux (ntfs-3g actually) won't mount your NTFS drive if it is hibernated. So I'd really avoid booting the other OS after hibernating one.

It smells like Linux has been here! I can't STAND that guy or anything he touches, so I burned the folder just to be safe. You can thank me later."

This pretty much sums up Microsoft's reaction to Linux in a nutshell. It's precisely why articles like the one we are commenting on exist. The answer to the question that the article poses is "Because Microsoft hates competition and acts like a petty spoiled brat. Get back to us when they grow up."

Microsoft's relationship with linux is actually a bit more complicated. It was a top 5 [1] contributor to the linux kernel in 2011 and a top 20 [2] contributor in 2012. The reason here is because linux virtualization is a big deal for Microsoft Azure.

Although the rational here is fairly clear: having good linux support for Azure helps Microsoft sell its cloud service. Having good linux support for Microsoft filesystems helps people move away.

[1] http://www.zdnet.com/blog/open-source/top-five-linux-contrib...

[2] http://www.geekwire.com/2012/surprise-microsoft-list-top-lin...

I'm aware of Microsoft's Linux kernel contributions; I've also been around long enough to remember the woes of NTFS compatibility, CIFS compatibility, the Halloween documents, the "virus" accusations, the SCO debacle, and not least of all relevant to this current conversation, the fact that exFAT is basically banned from an FLOSS implementation due to onerous licensing and software patents.