Hacker News Reader

Comment by apatheticonion | Hacker News Reader

Related tangent: Something I don't fully understand (perhaps I just haven't found a project that facilitates it) is why there isn't a Windows extension (driver?) that allows for native mounting of ext4 partitions within Windows explorer.

Surely, given the Linux native file system is open source, adding the ability to mount ext4 partitions natively should be something people can add to Windows?

I have seen third party applications with custom file explorers that can open ext4 partitions (in the same way you open a 7zip file) and I also understand you can mount linux partitions via WSL to access them via explorer - I would just love it if there was a way to natively mount ext4 in the Windows shell.

Up until now I have been using NTFS as my "universal" format - for drives shared between Windows, Linux and MacOS. I think exfat has recently gained support in all three platforms but it's not reliable for an internal hard drive (I think?).

View on HN

> Related tangent: Something I don't fully understand (perhaps I just haven't found a project that facilitates it) is why there isn't a Windows extension (driver?) that allows for native mounting of ext4 partitions within Windows explorer.

Such projects have long existed, but I suspect there's a lack of interest.

It's a difficult technical problem with a narrow usage niche. You need somebody who wants both Windows and Linux, and wants to use the same physical disks. Today, why bother? You can use a NAS, cloud storage, virtualization, etc.

Wanting to dual-boot sometimes isn't that rare, surely. And local storage for documents remains popular too. It seems to reflect the reality that serious Linux development effort has been very server-focussed for a long time.

These days probably quite rare, except for gaming. Virtualization is far more convenient.

Yeah, if you're going to exclude the common use cases, obviously it's going to be rare. (:

People still use local storage.

(I'd also like native ext4 support in Windows.)

Yeah, but when I boot Windows for gaming, I don't care about sharing data with Linux.

And given the availability of cloud storage, I can just upload whatever little I need to share.

Not all dual boot systems are "main OS" plus "wintendo." Quite a lot of the ones I encounter on personal machines are, certainly, but people doing actual dev stuff on both is still a use case.

Valve is working hard to change that.

Used to dual boot, but with the combo of steam/proton and VFIO passthrough + looking glass, it’s been really solid to just run both at the same time. File sharing between the two is pretty easy in that case, because it’s just the usual rsync/scp tools or SMB share.

Although, I’ve found I very rarely need the guest for gaming anymore, more so for opening the odd Photoshop file and similar tasks.

This is where I am at now.

In 2010, used to dual boot. In 2014 or so, I switched to VFIO GPU/SSD passthrough and never booted to Windows again. In maybe 2019 or so, I pretty much stopped using passthrough even, though this is partly because I stopped playing a few games that proton didn't run (mostly because of e.g. Easy Anti Cheat, etc).

I don't even have my windows ssd installed in my tower any more, that's how little I expect to need it these days.

Virtualisation is really laggy if you have no GPU acceleration, there are ways to get it working but they either need two GPUs or are still slower than native

When I dual booted a hackintosh and windows (2015) I did so on 2 different drives so I wouldn’t have windows scribbling over my boot sector

Sure but the Linux audience is certainly not one that pays for such things. Like the Parent Poster explained, this is a hard and niche technical problem. Someone has to foot the bill for this, and apparently there is a "need" for it but no market to sell it.

The Linux audience is software engineers and the companies they who employ them.

So why haven’t such an open source application materialized after all these years?

Well you'd need to fund the cost of a kernel driver signing certificate and get it through WHQL as well. That's just for a start. So this wouldn't be something you could build yourself.

Surely you’d just need to turn driver signing off

Back when I was a desktop Linux user, a very sizeable portion of the other people I knew that used it weren’t “software engineers”. They were ‘power users’. I don’t think that my experience was all that atypical.

The need is more personal than corporate.

There are corporate solutions (like the Paragon drivers), they just suck. Paragon tried merging this code into the Linux kernel, but the code was so bad and unmaintainable that it was rejected. The FOSS solution is using FUSE, but that requires a UNIX-like OS for easy porting. Unless Windows ditches the NT kernel altogether, I don't think you can expect native filesystem extensions beyond NFS support.

GNU philosophy is not about moneymaking or footing the bill. Sometimes a problem gets worse when you throw money at it.

If there was a Linux OS focusing on desktop/laptop users that offered a highly polished user experience - comparable to the best of MacOS and Windows - I would be very happy to pay for it.

I am probably in the minority of Linux users though.

I do not find macOS or Windows to be polished. Linux isn't either. They all just have different areas of roughness.

> "Sure but the Linux audience is certainly not one that pays for such things."

Eh? People just pay for their stuff. The problem is there isn't really a market for OSes (as a consumer), period. Unless you build a PC yourself, which is not the norm, you don't usually even buy an OS.

This has nothing do with whether the linux audience pays for stuff or not...they pay fine. It is true that it is relatively niche even for linux folk to want to do this sort of thing, but that has more to do with laptop vs desktop form factors than the market. If it were a common need, I think it would be a common thing found on the market. In fact the existing ext4 stuff for Windows indeed used to be paid, but this was primarily for Windows users, Linux users have had no issue accessing ntfs drives for ages, and generally didn't really enjoy giving Windows access to their drives anyways, what with the market for viruses and whatnot...

Why would I dual boot when I could use a VM?

For performance, to use the entire RAM and CPU of the bare metal machine

The overhead of VMs, properly provisioned, is minimal these days. Even going with card passthrough just works.

That doesn’t work if you have one GPU (unless you shut down the Linux desktop which defeats the point)

You need a whole damn extra card for passthrough. With the price of today’s high end cards, that option seems… less than attractive.

Let alone trying to fit 2 3-slot GPUs in your machine, or have enough PCIe lanes to take advantage of them

Single GPU passthrough: https://github.com/joeknock90/Single-GPU-Passthrough

For what?

For me dual boot has ended the day VMWare and Virtual Box became good enough, that was around 2010.

I mean…using desktop Linux in the first place is already an incredibly harsh qualifier. macOS and even Windows (+ WSL) are no doubt serving the needs of many people that need a *nix environment for their work, and eating into the percentage of people that would otherwise push for Linux to be supported by their employer, or use it at home. That and the ubiquity of containerised workloads.

It’s really not outside the realm of reason for the subset of those people that want to use Windows for something other than playing video games is small enough for there to not be the base level of interest needed for this stuff to get off the ground.

Linux has good NTFS drivers. If you want to dual boot and share files, you just make three partitions: Windows (NTFS), Linux (whatever the cool kids are using these days), and Shared Data (NTFS).

And before linux had good NTFS drivers, you just put your shared data on FAT32.

EXFAT is another option these days.

In my experience, exFAT support in Linux is worse than NTFS support (and NTFS is more likely to be installed out-of-the-box). If you also need to support macOS, then exFAT might be an option, but exFAT lacks journalling and doesn’t scale too well due to cluster size/count limits.

On the contrary I have the feeling dual boot is a thing of the late 90's-early 2000's when processors didn't come equiped with virtualization extensions and virtualization was slow as hell.

Having to reboot is so inconvenient, sooner or later ina dual boot setup you leave your non-preferred env colecting dusts and cobwebs.

Back in the day, and I mean like mid-late 90's, you could actually install the Linux kernel, files etc., straight onto a Windows FAT partition and boot into it.

Not exactly what was being asked for, but a weird old fact I'd forgotten about.

Sometime in the early 2000s, when microarchitectural features for virtualization were rare, I used coLinux in a working capacity. It has a design was amazing at how well it worked given the constrained size of the code changes. In short, it ran a copy of Linux in supervisor mode in addition to Windows (this is the "driver mode"). At the same time. Both in supervisor mode. As a giant coroutines yielding to one another.

https://en.wikipedia.org/wiki/Cooperative_Linux http://www.colinux.org/publications/Reprint-Aloni-OLS2004.pd...

A friend of mine has been using this setup for a very long time do be able to write music and work on the same station. I remember I was amazed at how solid the thing was.

Does anyone know if there's a relationship between colinux and how ms eventually ended up implementing wsl ?

Not so much. WSL1 was a too-audacious attempt to implement enough Linux-style system calls in Windows to run Linux software. Which it did surprisingly well, considering...but also, often strangely, and slowly.

I think the name is a bit ironic, since the whole idea is to avoid using any Linux code in Windows, but implementing system calls so that the non-Linux parts of a Linux distribution could pretend Windows was Linux. GNU/Windows-pretending-to-be-Linux, as it were.

WSL2 is virtualization-based, so it could be seen as more comparable to Docker's installation package as seen on non-Linux platforms, or Parallels: a somewhat elaborate attempt to improve the virtualization experience in interoperation with the host, e.g. setting up NAT, network file systems, or installing special drivers.

I don't think coLinux offers as much as it did, now that virtualization micro-architectural features are routinely available. At least one part of coLinux that took up quite a bit of its code was special drivers to interface with the host OS. This code would still be useful and has parallels in current approaches, but the decisive trick of toggling between two kernels running in supervisor mode has less room to be useful.

Also, you could only imagine the difficulty of identifying the origin of bugs in that set-up.

I was really quite fond of colinux, out of assorted VM tech, colinux, cygwin and WSL1 and 2 that have provided me with enough of an X11+xterm+ssh rig to get work done comfortably on a windows machine I think colinux and WSL1 have been the least friction overall.

Reminds me of Wubi - I had a Pentium 4 box with a BIOS password that wouldn't clear, and this let me turn it into something 'useful'

There was a distribution called WinLinux that did this, iirc. Installed like a normal piece of windows software. Was my first foray into unices when I was a young kid. There were some fun games in that distro!

Or just using NTFS since Linux now has good support for it.

The niche surely ain't that narrow, especially as Linux-based devices like Raspberry Pis and Steam Decks grow in popularity; being able to ready EXT-formatted SD cards and such seems like it'd be valuable even from Windows.

It might be convenient, but it is also more complex than just being able to read file systems. External disks or partitions containing data in particular will / should always be fully encrypted nowadays, so you'd need interoperability of disk encryption schemes as well (dmcrypt, bitlocker). NAS can handle that transparently.

Now that the new NTFS3 driver is out in the wild there's also not much need. The number of people who boot windows and need to access an ext4 partition is tiny compared to the number of people booting Linux who need to access NTFS.

Paragon has been doing it for quite a while. You just need to pay extra. https://www.paragon-software.com/business/extfs-for-windows/

contact Sales for a quote. I guess the price depends on how many files you plan on storing?

$20 if you're a home user?

That's the business page, the home user page shows €19,95 for me.

Don't use this. I once tried it and it changed the UUID of the Linux partition without any warning. Grub was unable to pick up the partition and boot, so I was stuck at grub rescue.

God knows what other bugs their software has.

To your last point: try UFS! I use it for cross-platform flash drives. Better than FAT32, anyway.

I guess you’re referring to Universal Flash Storage rather than Unix File System? (:

Maybe UDF?

Probably. Last time I check UDF is a format supported by the 3 major OSes out of the box.

I recall getting UDF cross compatibility required a bit of non-trivial work[0], did this improve recently?

[0] https://github.com/JElchison/format-udf

Yeah, UDF. UFS won't get you terribly far with cross-platform support... Thank you.

> I think exfat has recently gained support in all three platforms but it's not reliable for an internal hard drive (I think?).

I've been doing this for a few years now. It just doesn't support some stuff, like permissions, but for just a pile of files, it's fine.

No symlinks, no transparent compression… there's quite a few mission things

Missing*

I haven't stubbed my toe on the former yet, but I agree it's not great. I'm mainly storing media, photos, etc. (relatively not compressible) so the latter doesn't matter much to me. I think that's probably a common use case for a drive you can read anywhere, so I still like ExFAT for that, generally speaking.

Is the performance decent for the ‘cost’ of lacking features?

I would say yes, but I'm not pushing it exceptionally hard. I would say it makes a good default unless/until you run into a problem with it.

Writing filesystem drivers for Windows is extraordinarily difficult, more so than generic drivers and the result is hard to call GPL compatible because a signature which is basically not obtainable for individuals is required to load them.

> I think exfat has recently gained support in all three platforms but it's not reliable for an internal hard drive (I think?).

It's not, and recovery tools are still lacking. Keep using NTFS for now.

exfat’s reliability “issues” are by design— it’s not journaled, to simplify implementation (and reduce resource use) on embedded devices and reduce wear on flash media.

It’s not a replacement for NTFS in applications where it’s already being used (large disks, anything where important data is being stored). Rather, it’s a modernized replacement for FAT32 for things like camera memory cards, eliminating some of FAT32’s limitations (like the file size limit) while remaining similarly lightweight.

There used to be an ext2 driver for NT, I think opensource even, but there simply had not been enough interest to keep it updated or built for newer versions

I installed Debian on WSL for the very first time a few weeks back. Windows explorer gives access to the Debian folder while it is running and no access otherwise. Had me scratching my head. I don't know much about virtualisation, but if that is the key, they could probably have a highly customised, small Linux kernel running all the time perhaps.

WSL uses the 9P protocol for filesystem stuff[1]. There's a 9P server running in Debian and a 9P client running in Windows to connect it together

[1]: https://en.m.wikipedia.org/wiki/9P_(protocol)#Server_applica...

This looks like what you need: https://learn.microsoft.com/en-us/windows/wsl/wsl2-mount-dis...

Pretty sure there isn’t an ext4 spec, it’s just the reference implementation. Microsoft could build something that is compatible, but keeping compatibility as the reference implementation changes may not be straightforward.

The counterpoint to this is that ext4 can't change dramatically enough to cause problems without breaking compatibility with older kernels or older filesystems.

Certain features (like case-insensitivity) already do break compatibility, as I found out the hard way trying to get GRUB to boot from an ext4 filesystem with said features enabled.

When could ext4's specification change?

It's not just the MS implementation that might break but everybody's file system may be in danger.

Filesystem is supposed to be as backward compatible as it should be.

Ext4 was explicitly designed with maintaining backwards and (limited) forwards compatibility in mind precisely for the reason pointed out in my sibling comments.

Depending on the filesystem features you enable, you can even mount an ext4 filesystem with the ext2 kernel driver, and you can already mount an ext2 or ext3 filesystem with the ext4 kernel driver.

A large part of this compatibility is due to the bitmap of compatible, compatible read-only, and incompatible filesystem flags in the filesystem superblock.

For example, when ext4 got support for extents, that's an incompatible feature; you cannot mount an ext4 filesystem with extents with the ext3 kernel driver. This does not even require ext3 to know what an extent is because it's just indicated as an unknown (from the ext3 driver's perspective) incompatibility flag.

On the other hand, the implementation of sparse superblocks (keeping fewer copies of the superblock around to allow for more blocks to be used for file data on filesystems intended to house lots of large files) is merely a read-only compatibility bit; you can mount an ext4 filesystem using sparse superblocks with an ext2/ext3/ext4 driver that does not support them, in a read-only manner. This cannot be mounted read-write because the implementation may try to place a filesystem superblock where file data is supposed to be, which would lead to at best wasted space (negating the feature) or at worst limited filesystem corruption.

When feature changes that could break things are made to the ext4 implementation in the Linux kernel, they are always done so using these (in)compatibility flags, ensuring that only implementations that can entirely support the feature can mount them read-write, and that implementations whose ability to read would not be affected can still mount them read-only. This allows you to create future filesystems (using e.g. mke2fs(8)) and not turn those features on while doing so, if you want the filesystem to be used by other implementations. Something you already have to bear in mind if you're creating a filesystem using a modern mke2fs but intended to be read by ancient Linux kernels.

Maybe you are looking for https://www.paragon-software.com/home/linuxfs-windows/

ext2fsd and ext2ifs do exactly that, although neither of them is very actively maintained (but do they really need to?)

I've used ext2fsd in the past and it worked well. I don't think you could boot windows off of it but you can certainly start touching your Linux drive from there.

It's entirely due to Microsoft's hubris.

Yeah. Screw Microsoft for not supporting a file system with a rounding error desktop user base.

Microsoft didn't support ext because too few people were using it to justify the effort, yet somehow they went to great lengths and implemented the whole WSL, and... ~twice at that - for a possibly smaller user base?

Reply on news.ycombinator.com