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.
God knows what other bugs their software has.
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.
People still use local storage.
(I'd also like native ext4 support in Windows.)
And given the availability of cloud storage, I can just upload whatever little I need to 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.
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.
GNU philosophy is not about moneymaking or footing the bill. Sometimes a problem gets worse when you throw money at it.
I am probably in the minority of Linux users though.
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...
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.
Having to reboot is so inconvenient, sooner or later ina dual boot setup you leave your non-preferred env colecting dusts and cobwebs.
Not exactly what was being asked for, but a weird old fact I'd forgotten about.
https://en.wikipedia.org/wiki/Cooperative_Linux http://www.colinux.org/publications/Reprint-Aloni-OLS2004.pd...
Does anyone know if there's a relationship between colinux and how ms eventually ended up implementing wsl ?
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.
It's not, and recovery tools are still lacking. Keep using NTFS for now.
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.
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.
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.
[1]: https://en.m.wikipedia.org/wiki/9P_(protocol)#Server_applica...
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?).