Hello i think that is not convenient that a free and opensource system struggle with some black box inside.
Exfat on sdcards, it’s cool for windows users.
But what is for linux and mac users?
format and use exfat only for sdcards without to know how it use it?
If there is problem it can’t mange anythings for repairing or retrieve something.
Maybe it could break the sdcard.
I’m a linux user, and have a galaxy s10+. Then shortly i get 2 sdcards corrupt on boot sectors and backup bot sector. Fine, and 2 2 time for both. It happens regularly.
My linux can read it again. But not solve the issue. i’m not skilled enough to use testdisk for it.
sdcard higher than 128GB to copy is really hard to handle in time.
Anyway, i tell me why should i use a partition typ that my os at home can’t manage, repair and i don’t know what.
Why a linux os like android, give no other choice than exfat to use, like exfat?
Use a black box which not really work efficiently (any software may have an issue and some bug, that’ ok). No alternative possible is deadly
Android is not a Linux OS, per se, it just uses the Linux kernel. Comparisons pretty much end there.
For full compatibility across operating systems, exFAT is not a good choice. Good ole FAT32 is the way to go unless you need large file support (over 4GB).
For external storage Android (custom ROMs at least) does not seem to support anything other than FAT32 (reliably) but supposedly supports ext3/4 natively also. Haven’t checked though.
Maybe check out this old thread about a similar subject.
Supposedly Android 13 will be able to read/write exFAT. Some A12 ROMs with kernel 5.x, too.
Many thanks for your interest and your response.
I don’t want to discuss about what is exactly a linux os.
According to your short definition, seems that there are no Linux OS, all distrib use only a linux kernel…
And yes you’re right for storage smaller than 4GB FAT32 is the way to have largest file support. Is the best, for only less than 4GB memory.
For sure that android could support ext3/ext4. The interfaces are online free to be used according their licenses, every one could access on it.
exfat is closed, and not free.
But i’m not sure to understand the point of your discussion, and the one of the old post…
/e/ is not based on lineageOS and has the motivation to make a gap, a distance with the google service ?
Apart of Linage OS motivation, would be to add some missed functions that the original android OS not give?
Thus to have a better liberty, and a largeness of partition typ support, would be simply to bring the ext4 or ext3 why not btrfs support on it. We don’t need all 3, one is good.
That’s quite frustrating to use the exfat black-box on my phone as linux user, and can’t manage something to repair when this black-box has a fault.
I can do nothing.
It would be fair if we can choose the partition typ like jola do with sailfish os, despite android do.
/e/OS is /e/OS it could have this as specificity by the alternatives ROM.
Nice rabbit hole.
Probably it will come down to Android being a mess, but I’m no developer and can spout something unspecific like this while getting away unpunished .
I’m under the impression Android itself uses ext4, so in general the support is there.
Android doesn’t easily allow using ext4 on an SD card, but smart people got this to work in the past.
The more recent example, however, ends with “Hey just updated to LOS18.1 and this approach seem not to work anymore” … which leads me to this unsolved LineageOS 18.1 issue …
There’s always room for type::Improvement or type::Feature Proposal .
And if you want to talk to the people who could perhaps make happen what you want, that’s where they are.
“Issue” is just the name of an entry there, because GitLab decided to call it that, just like “Topic” is the name of what you opened here in this forum, because Discourse (the forum software) decided to call it that.
interesting.
I’ll give a look on it
For adding a ticket, we need to create gitlab account.
Don’t need anything by gitlab, but if it could drive some things forward…
I thought that here the community website is the under some other functions the gather point of the user request.
But i didn’t really found where are the user request channel. seems to be a little bit spread overall
Didn’t saw it, thank you for bring me aware of it.
I think the best (technically spoken) would be the gitlab channel definitively.
But with my post and the wish-list one, maybe I could gather some interested people and some idea to polish the request.
Yes, exfat is unnecesserily difficult to setup correctly in Linux and Mac - but it is hands down the best solution if you need to move files between Linux, Mac and Windows. Just last week I stick 128 USB-C stick to my /e/OS, copied large video files on it (so VFAT won’t do) and just used that stick to copy files to my Linux laptop and wife’s Macbook. All my external disks are exfat for just this reason - those disks work on all main operating systems.
Now, you need to get partition table and file system type correct or nothing happens. Windows may be more forgiving but Mac and Linux require GPT partition table and Microsoft Basic Data filesystem type partition and then ofc the actual exfat filesystem.
Application support is spotty at best. I’ve ended up using parted to set partition table GPT and then cfdisk to actually create the correct partitions. But investing some time on finding what tools to use and how to use them can give you fully OS independent file storage
i understand your situation, according this os compatibility: Comparison of file systems - Wikipedia
that’s clear for you.
however UDF might works too, but i don’t know if it’s really flexible.
Anyway, you mean that you use the tool “parted” to set a GPT partition table first, then cfdisk to create the partition as exfat ? with extra or particular options ?
I i tried to create with gparted all the card, and the /e/OS don’t accept this.
I’ve no problem that android or /e/OS create the partition as exfat, or any other else. But it should have more support on it. If it’s lightly corrupted, it should have the possibility to repair, or give the possibility to other tools to repair. In Android store, it seems that all the tools are a joke. and my linux desktop OS, can do nothing…
parted /dev/sdb
mktable to create GPT partition table on the disk. Unfortunately mkpart command doesn’t seem to recognize/support exfat so you can’t create partition for exfat use here
cfdisk /dev/sdb
should recognize immediately that /dev/sdb has GPT partition table in use. Then just create a primary partition with “Microsoft basic data” type
mkfs.exfat /dev/sdb1
finally to create the actual exfat file system. Now /dev/sdb1 is ready for use
Also, you could use fdisk utility to do steps 1 and 2 but I think parted and cfdisk are more user friendly.
I revisited gnome-disks utility (GUI) and it seems to work also. I used to have some issues with it earlier but those may be because of having fuse-exfat and exfat-utils installed. Removing those and installing exfatprogs (and use kernel’s exfat support) apparently fixed things for me.
I’m not a big fan of exFAT either, but your points don’t really hold true anymore these days.
exFAT is now part of the mainline kernel since quite some time and works really well on Linux.
(Of course also on Windows. Don’t know about OS X, but I’d be surprised if it isn’t well supported there, given how many artists use that OS.)
Also, you actually don’t really have a choice with many devices, as the SD card specification requires the usage of exFAT for cards with a capacity of 64 GB or more.
Many devices (e.g. cameras) do not work or work badly if you provide them with a 64+ GB SD card formatted with FAT32.
(And yes, I’ve really tried to get that working and gave up.)
The main concern with exFAT is that Microsoft holds patents covering it, but they have now made it clear that the Linux kernel is fine (which also covers Android devices as they use the kernel).
Hence, the filesystem went into the kernel.
There isn’t really a reason why you would restrict the usage to one of the 3.
First, if you provide support for ext4, you also support ext3 (and ext2), since the ext4 driver supports all these formats.
Second, I don’t see the big deal with providing support for ext4 or btrfs.
It’s just two additional modules, so maybe 1 MB additional data.
These modules are typically only loaded when such a filesystem is mounted, so they don’t clutter your runtime either, unless you provide an SD card with these filesystems to the device.
Therefore, providing limited capability (read/write of ext4 and btrfs, but unable to create such filesystem) should be a really simple and quick change. Just have to set two parameters for the kernel configuration.
UDF is not really well maintained. Especially the tools for it on Linux.
Also, Windows has a rather restricted or limited use of it, although it works a bit better in recent versions.
I know, because I’ve actively used it as a filesystem on USB sticks in the past. It works, but other solutions are better.
Trust me, you don’t really want to do that.
Good stuff. Thanks. But… sure the mainline kernel supports the filesystem but not everything is running mainline, phones especially.
So yeah, exFAT is great if all the devices and hardware one is using supports it. Otherwise one has to use something more “universal” for the time being.
Hmm, I also have to check if my non-Linux OSes are good with it.
That’s true. My FP3 uses kernel 4.9, which is an old lts Linux kernel.
(which btw just went EOL last week, so it won’t be maintained upstream anymore)
btrfs however should be present in that kernel as well. Not the most recent version, but it should work well.
There are some restrictions for an older version like that, but afaics (looking at the manpage of mkfs.btrfs and btrfs(5)) the only one relevant for a phone device might be compression support, for which zstd was only added with version 5.1. Otherwise it should be fine.
Of course I don’t know if there are other devices with even older kernel versions.
The driver for exFAT is based on Samsung’s sdFAT driver that they accidentally released in 2013, but open sourced officially soon after. Since then, it was mainly used as a fuse driver to provide exFAT support on Linux. So it was around much longer than 2018. It just wasn’t integrated into mainline due to the patent concerns until Microsoft finally contributed the patents to OIN in 2019 and published some specs.
The fuse exfat should still work, but it wasn’t updated since 2018:
Also, I don’t know if fuse is a solution that is desirable on a phone.
I also found this:
It’s a project that brings exfat to older LTS kernel releases, maybe that could be used, if additional kernel modules are acceptable.
.
.
