-
Notifications
You must be signed in to change notification settings - Fork 840
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
DrvFs support for FAT volumes #801
Comments
Linux itself supports FAT/etc. Its mechanism is basically #1 -- it lies about permissions; you can configure (per mountpoint) what it should pretend that the permissions are. That approach has been in the kernel for decades(?) and has worked well for a great many people. |
This has been previously raised on #530 (comment). (That ticket discusses other things as well; I don't think this is a duplicate.) |
DrvFs on NTFS already basically already "lie" about "Linux" permissions, and it is my understanding that only VolFs depends on alternate data streams, so disregarding implementation details I don't think it should be too tricky to support FAT? |
Linux has a driver for FAT32, and I think it disables linux permissions being set there anyway and just fakes them for reading based on the mount settings in fstab? Maybe something similar could be done in Windows? |
+1. I'm surprised there's no support for FAT volumes. I have my hard drive partitioned for 2 OSes and documents storage which is an exFAT partition. It would be nice to be able to access these files so I can start development in Bash. |
@katacarbix change docs storage to ntfs. Linux can read ntfs with the ntfs-3g driver project pretty well. |
I don't think Mac OS can read and write NTFS |
Not sure, maybe it's possible though if ntfs-3g has been ported to openbsd? This looks promising maybe: https://github.com/osxfuse/osxfuse/wiki/NTFS-3G Page also says El Capitan supports mounting NTFS natively, but maybe it's readonly? That project seems to allow you to mount in RW mode. |
Macs have supported read-only NTFS natively for a while, and read/write via the above project. They gained unsupported / off-by-default native read/write support at some point; I'm not sure when. |
@aseering It's ironic, but NTFS, the most closed and proprietary FS in the market, the one that still doesn't have full documentation of all of its functions, is also the one with the most cross-platform support =) |
Regardless, I would rather they implement exfat support than have to switch to ntfs. |
@katacarbix The main problem with that is that MS will release exFAT support when they decide to do it (if they decide to do it). I think exFAT is considered legacy within Microsoft. On the other hand, NTFS will work fine, even if it takes a little bit of reconfiguration on your part. Since there is a pretty simple solution available, I don't think that MS will rank the idea extremely highly in their list of priorities. |
But what about for flash drives? You probably don't want to convert those to ntfs every time you want to use one on bash on windows |
@katacarbix fat32 is different from exFAT, and still there is no reason why you couldn't (if you were absolutely bent on interop) just format them with NTFS (unless you are working with bootable efi devices, but then you probably shouldn't be using WSL on that kind of thing, I think) |
@fpqc If you're sharing a partition (e.g. git repo partition) across a Mac and a PC (e.g. Macbook Pro) then exFAT is the best choice. And I'm actually using that and Bash on Windows can't see my repos right now. Wish NTFS and ReFS were open-sourced but till then I'm voting +1 for FAT32 (removable veracrypt encrypted USBs) and another +1 for exFAT (multi-platform drives). |
@SidShetye Why not NTFS? It is supported on mac! |
Not officially, you have to make unsupported changes to |
Support for FAT drives was added in 16176. |
Currently, DrvFs only supports NTFS and ReFS.
FAT32 and exFAT are commonly used in multi-system environments where data portability is desired. (FAT12 and FAT16 to a lesser extent, but while you're at it...)
Due to the simple nature of these filesystems (no permissions), it's expected that these filesystems Just Work, although the reality is that DrvFs depends on Alternate Data Streams that the FAT family does not support.
Acceptable workaround #1: Just lie about permissions. Any binary that changes permissions gets told the operation succeeded. Any binary that reads permissions gets told they're 0777.
Acceptable workaround #2: If too many permission-setting binaries fail because they verify the settings took effect, store exact permissions in memory and discard on exit. Permissions default to 0777.
The text was updated successfully, but these errors were encountered: