IssueTracker

Specifically, ext3 support is needed for the SD Card.

No support on froyo as well? Whatz the plan? Is it going to be supported in the future?

Has this feature been implemented in FRF72 froyo release?

From the think of it, I hope this feature is actually not implemented... Yes files take more space, but thats the developer job to manage its space properly. Having the file system as fat makes our devices readable by other medium. For exemple, if you plug your device right now in any sound system that support usb in you be able to controle your music to that device. If we where using extX that wouldnt work. Developpers should optimise their files on the device knowing that what is the block size. In your case, the tiles of your offline maps should have been stored maybe 4-6 tiles per file which would have us the storage properly...

FAT is horrible beyond description as a filesystem (all very well documented elsewhere).  If other filesystems were at least supported you'd have the option.  There is an ext2/3 driver for Windows although I do not believe it works on Win7.

Adding support for extension of the application storage space into an ext3 partition on the SD card would also give customers a better choice in application vs phone storage than the limited implementation in 2.2/2.3.  (This has already been achieved by various dev ROMs).

Yes, vfat really sucks. This is how I got apps&data to work on ext3 /sdcard on 2.2
http://android.modaco.com/index.php?s=&showtopic=308568&view=findpost&p=1511967

This could be implemented very easily: Just replace the hard-coded 'vfat' trough 'auto' where mount is called. This forces the system to mount whatever file-system is used on the first partition on the sd card.

Please bring us ext3/ext4 support for microsd!
Fat is just a crappy filesystem.  I know it's standard for flash drives because it's old enough that microsoft isn't actively sabotaging compatibility, but as a linux user I'd really prefer to not have to touch that filesystem.
As OP said, fat wastes lots of space with small files.  It also lacks a journal and tends to suffer corruption frequently, and it's lack of support for unix permissions means that I have to use a loopmounted extfoo filesystem if I want a place to put a debian chroot.

It's very rare that I'm using a system where FAT32 is necessary, and when I am I can deal with the fact that my phone doesn't work as a thumbdrive. FAT32 should be default and everything should work as expected on FAT32, but it should still work if I format the card to ext2/ext3.

Recently FAT32 was broken on my microSDHC by http://code.google.com/p/android/issues/detail?id=17684 . I would be happy to switch to ext4, but it is not supported.

It would be neat if Android used EXT4 on the SD card, but presented it as a FAT32 file system to the host PC.  It would then still be compatible with Windows and possibly keep the benefits of EXT4.  If that is not reasonable then just having a setting in the storage menu to select between FAT32 and EXT4, with a warning that the SD card will be erased when changed.

As has been said, I believe support for ext FSs should be there out of the box. Possibly use FAT by default, so the "typical" user can keep using it as a thumbdrive, but you may still choose to use ext FS if you so wish, to avoid fragmentation etc. Android is based on the linux kernel, which uses ext by default, so it should be possible

By default, Android's linux kernel is built without EXT filesystem support. Yet even after re-compiling and flashing a custom built kernel with EXT support, the android userspace refuses to recognize the SD-card as an SD-Card and complains that one isn't inserted.

Somewhere there's a script that's looking for a fat32 partition on /dev/mmcblk0p1, and only when it sees that will it run mount and let the rest of userspace use it.

Android's kernel most certainly already has ext filesystem support already.

It is used for the userdata partition (ext3 in froyo and ext4 in gingerbread)

All of my phone's partitions (/data, /system, /cache) are type rfs, but my phone shipped with eclair and I haven't run a stock kernel on froyo, so I guess I can only say for certain that eclair did not have EXT support.

plz add ext# format support for Android's Linux Kernel,thanks~

please add ext# support in the linux kernel, most devices hasn't many space in the internal memory, plus the partition layout designed in android requires a lot of wasted space.

to commenter 19:

temporary,you can install ext#.ko modules while android system boot-time to get EXT# format supported.

Wow, two years later. The problem still exists.
It's a simple change, please add EXT# support and recognize sd-card type automatically.
I don't think it would be trouble for Windows users, because we just want EXT# support and keep the fat32 default. But you should let the EXT# sd-card works with stock Android.

please add support for ext2/3/4, I see no problem with hawing fat32 as default but at least make it so i can mount other filesystems, this is really annoying with big files

I use Linux exclusively, and would like to be able to use my ext3/ext4 external drives with my Android device.  Linux (the underlying OS of android) supports these quite well (they're native for them), and can autoswitch on recognizing the filesystem of the underlying drive.  This would better support your Linux based customers.

Why is this still an issue?  ICS is using MTP and doesn't even officially support USB device mounting, so the device has every chance to switch to a good, heck, half-decent FS rather than relying on the severely antiquated, slow, feature-lacking abomination that is FAT.  The name says it all, FAT is well...fat, and ugly, and stupid, and worthless.  As people want to copy more large movies, OS image files, ROM zips, etc. the file size limitation of FAT becomes a huge pain.  For large (32GB and up) cards it makes no sense to use such a limited, pathetic filesystem.  The two I'd suggest are NTFS and ext2/3/4 as they are both fairly well supported, have a much more useful file size limitation, and are faster.  NTFS works perfectly fine in Linux these days, so there's no good reason to omit it (yes, even read/write works!).  Ext2/3/4 is Linux's primary filesystem and is already heavily used under the hood, plus it's well supported on Linux hosts and reasonably well supported with ext2fd on Windows (32/64 bit, even Win7).  NTFS support has been in Linux for over 5 years now, with reliable writing supported for several of those years.

I have personally used both NTFS and ext3 partitions on my SD card on my Android devices without issue.  If you simply issue one proper 'mount' command it works fine.  So, the hard part is done, why is this simple little vold patch so difficult for you?  It really just makes vold a waste, I might as well delete it and mount everything with mount commands in an init script because it actually works.

[Comment deleted]

It does not work so much, because ext4 enforces permissions. And Android apps have a crappy umask of 0077. For a system with UPGs (user private group), only 0002 or 0007 makes sense. And yes, Android has UPGs and uses the sdcard_rw group for write sharing and the “others” category for read sharing (with everyone by default). On Android, only 0002 makes sense.

E.g. I can take a photo, but the viewer can’t open it (permission denied).

>> It does not work so much, because ext4 enforces permissions.
With proper mount-time options this is not an issue; As all the mounting in handled by vold anyway, what would be the problem to add one line more to the mounting function for ext3/4 ?

There are no mount-time options to ignore permission checking on ext4, sorry.

I’ll switch back to FAT, because a couple of apps store files under one uid (mostly indirectly) and try to read it from another. This affects photos (sharing), audio records and some apps composed of multiple .apk installs. – You can do a “chmod -R g+rwX,o+rX /sdcard/*” but:

- you have to do that between e.g. taking a photo in the photo app and using it in the app that called for taking a photo...
- you have to prepare this with a “chgrp -R sdcard_rw /sdcard” and a “chmod 2775 [all directories under /sdcard]” or do the chgrp every time.

I got file system corruption with ext4 as well, but I believe now it is a problem between my phone HTC Desire and the SD cards. My Lexar card (class 6) only lost parts of it’s memory from time to time, a “Kingmax” card (also class 6) has now completely damaged blocks (no read, no write), and a new Kingston 16GB (no class written on the card) runs fine so far (two weeks only).

This also explains better why the reports of file system corruptions are low and why I lost the partition table on two occasions (not part of any file system...).

is there a good reason why vold shouldn't support extfs for the sdcard?

fat is bad, mmkay. journaling please. if not ext then perhaps something better.

This issue is open since 3 years ???
linux comes out of the box with extfs and we are not able to use it for external storage just because changing some lines in vold is refused ???  Shame.  
I just fiddled around with the vold binary and strace and was close to 'fixing' the binary with vi; the patch should be quite easy.  
Is there a chance to accept the patch if I submit it here ?  

The permissions issue as described in #28 could be resolved using setfacl. This can enforce a specific group and permission set for all new files and directories without any additional fix ups required.

Oh wow. So what do I do?

I've just bought a 64GB microSDXC for the first time. Since FAT32 can only address a partition half the size, I went straight and formatted it EXT4 without even stopping to think that this wouldn't work with Android. On insertion, to my dismay, Android rejected it with the message ‘Damaged SD card’. Even the message is bad because unsupported is not the same as damaged! Infuriating!

Seeing the timescales of this issue, like many other important Android issues, I'm not going to hold my breath. That leaves me with the question of what to do in the meantime, which knowing Google, could be another few years. Do I send it back? Or should I format it as two FAT32 partitions? Or is there a filesystem well supported under Linux that Android supports as well that can address larger than 32GB?

The existing partition before formatting appeared in GParted as ‘unknown’ (black). (It wasn't NTFS for that matter.)

Had I known about this issue when I last upgraded my phone, this would have influenced my buying decision. When choosing, I was preferring a phone that only had 32GB internal storage but unfortunately lacked a microSD card slot, so I instead opted for a 16GB phone with upto 64GB microSD expansion to make 80GB (150% more than the other). Seeing as it now looks like I can only get upto 48GB via a 32GB card (or partition) if I want to also read it on my computer (which I do), I'm now thinking that I picked the short straw when choosing my phone because 50% more storage might not have swayed me from some features I was really keen on with the other phone. :-/

Well there you go, that's assumptions for you. I wouldn't be so grumpy when Android fails to do something if I didn't assume it could do it in the first place. But having used Linux for several years, it saddens me as to how many basic Linux things it can't do. :-(

Try formatting with extFAT.

(Sigh of relief.) GParted let me make a FAT32 partition that filled the 64GB drive (i.e. greater than 32GiB), and Android could even mount the partition!!! It turns out that FAT32 can actually address upto 2TiB partition size, so I don't know who is claiming there to be a 32GiB limit such that FAT32 can't be used beyond SDHC.

Of course, there are many other limitations of FAT32 compared to EXT, so I hope that this issue gets fixed before I reach those limitations. I also hope that the fix gets into 4.4 or back-ported to Jelly Bean so that my new phone will receive the fix in a future upgrade.

rahaman.riaz: Do you mean exFAT? That is severely patent-encumbered, and I would not currently trust the reliability of Free-software implementations because they have to work around those patents and a closed specification. Furthermore, it clearly isn't even recognised by my system; the microSD didn't mount when I first inserted it, and GParted displayed it as ‘unknown’.

Yes I was referring to exFAT. I formatted using mac disk utility application and the card loaded fine on my Galaxy Note 3 Octacore variant device.

rahaman.riaz: It seems that Android can do that via the ‘Erase SD card’ function under storage in settings. A point I made in my first comment was that I wanted to be able to access it on my PC (reliably). This card will be used for photos taken by my phone and other important data, and I have no need for this card to be compatible with Windows PCs since I rarely have to use one, so I'm not going to use a filesystem that has unstable support on Linux.

steve.garon, others: If this bug was fixed, for those of you concerned about legacy compatibility, what I sometimes do if I think I'll need to use a drive on a Windows machine is to make a FAT32 partition at the start of the drive big enough for whatever I might need to transfer to or from such a computer. I typically allocate no more than 5–10% of the drive for this purpose.

There are EXT2/3/4 browsers (file managers) and even drivers that let you mount drive letters under Windows. The fact that MS doesn't ship ext filesystem support on Windows doesn't seem like a good reason to avoid fixing this issue.

What is the major problem, anyway? Is it because android ext supports permissions and vFAT does not? I see 3 options:

1. Assume the user knows what they're doing. If they have permissions issues, they can fix it themselves. Since SD-Cards don't ship with ext on them, this probably isn't a bad assumption. You could even leave ext support something that needs to be enabled in the developer options.

2. mount the ext filesystem someplace else and then use bindfs (http://bindfs.org/docs/bindfs.1.html) to mount it with media_rw:media_rw permissions to /storage/emulated/0 (or whatever the proper path is on devices with SD-Cards). Then it won't matter what file permissions are on the original filesystem, Android will always see it as media_rw:media_rw and allow the user to access it just like it was vfat.

3. Patch the kernel to ignore allow a mount option to ignore permissions on ext file systems and then mount external media with that option.

This has become even more of an issue with KitKat removing general write access to the external SD card.  If we could format the external SD card as ext4 then all the problems they describe would disappear.

I don't want to use a MS-patented filesystem like FAT/exFAT, please support Unix-based file system!

Agreed!  Why is this still an issue?  I use Ext2 and Ext3 drives every day with my Windows machine, and that's irrelevant from their point of view with these new KitKat permissions anyway.

While adding support for ext , please enable support for LUKS.

Why not give the user the option to format SD cards as ext4.  Then allow the moving of apps to the ext4 card.  Those who need compatibility with windows can maintain it (they are not forced to format their cards to ext4), and those who want to move apps to their SD card can do so securely.  Not to mention all the other benefits that have been mentioned above (better file system).

I'd be very happy if this were implemented; still using an obsolete filesystem like FAT on 32GB cards is quite ridiculous IMHO. It also seems like supporting a proper filesystem should not be very difficult, since the internal storage already uses ext.

I'd be especially if this fixes the problems with saving to the sdcard on kitkat. I use a camera app from the play store, and the fact that I can't save directly to my sdcard is extremely annoying.

I've just discovered that there already some apps out there for rooted phones that create an ext3 partition on an sdcard and make some symlinks to integrate it with the root filesystem. It really would seem technically quite trivial to just add support for ext3 filesytems, even without the ability to format an sdcard as ext3 from within android...

I need help transfering all my stuff from phone to sd idk why it aint working wen i have a 16 gb sd card

5 years for a very simple fix? Obviously you don't care.

This is mostly already fixed as of KitKat, at least on CyanogenMod. The new FUSE wrapper deals with the permission issues that prevented this from working before. On CM11, it should just work. On CM12, there is one remaining issue with the Media Provider, which has a fix pending at http://review.cyanogenmod.org/#/c/100734/. I've tried it and it works. You don't want to use ext4 though, use f2fs instead.

I need to copy and move files from my phone to the sd card!!

Why when I bought my Samsung Galaxy S6 Active that came with a Galaxy Tab4 in mid June 2015 I also bought a 32 gig micro SDCARD and could at that time transfer files from my desktop PC like Mp3's to my Tabs memory card but now I can't? Any and all help and info would be greatly appreciated. I had thought this to be a BS Apple thing was why I brought a Android device. What's the deal?

[Comment deleted]

[Comment deleted]

[Comment deleted]

https://code.google.com/p/android/issues/detail?id=8111#c35
You might've gotten the "Damaged SD card" message because, and I'm guessing here, Android is always(?) running fsck_msdos on the inserted SDcard, and if this fails, it will show you that message and refuse to mount it.

I'm about to create a new issue because fsck_msdos must be bugged since it fails with "Damaged SD card" after reboot, and yet my laptop can mount it safely and the fsck.vfat program on my laptop detects no errors. It's only fsck_msdos which fails with "could not read boot block".

So, why is this relevant here? you may ask. Well, if fsck_msdos is always run(my guess) then you won't be able to plug ext2/3/4 sdcards because fsck_msdos' failure will stop the mounting process, even if it would know to mount the proper filesystem.

Thank you for your feedback. We have tried our best to address the issue reported, however our product team has shifted work priority which doesn't include this issue. For now, we will be closing the issue as "Won't Fix (Obsolete)". If this issue still currently exists, we request that you log a new issue along with the latest bug report here: https://goo.gl/TbMiIO and reference this bug for context.