Kudos to Google for hearing loud and clear the 127 people in that thread and potentially helped the numerous chromeOS community!

And here [1] are the cries of few thousands of souls that lost full access to their android sdcard. Hope you also hear their feedback louder and clearer! On the upside we learned how "Bring it back" is written in multiple languages. [1] https://code.google.com/p/android/issues/detail?id=67570

With SD cards, the "old way" had serious problems (security and robustness issues because apps could stomp on each other's data, all sorts of complexity and confusion on multi-user devices, orphaning private app data on the SD card when apps are uninstalled, no sensible backup possibilities for apps that depend on SD card data, apps not knowing whether data would be on internal or external storage because "/sdcard" means different things on different devices, etc.) that Google is trying to solve.

Google's solution required a compatibility break, but that doesn't mean they're just dropping all of the SD card use cases. KitKat introduced app-specific private data on external storage, apps can enable some simple sharing by the adding read permissions to their private data, the storage access framework can be used to support more complex structured sharing between and so on. Among other things, Google is even adding a new API in Android L that lets apps properly publish media (images, audio, video, etc.) from their private storage (including private SD card storage, which is when it is most useful) to the shared MediaStore.

Is this transition bumpy? Absolutely, especially for people who upgrade their OS or use an old SD card on a new device. Nevertheless, I don't think Google will go back no matter how loud the cries get. Google tried neglecting SD cards from Honeycomb through Jelly Bean (hoping they'd "wither away", I suspect). That failed. Now they have no choice but to do the hard work of putting external storage on a reasonable foundation.

I think it's really about Google control. They tried to remove SD cards completely and push cloud storage, but since that didn't go over so well, they'll emphasise the "problems" and their attempt at "solving" them by introducing some even more convoluted scheme for access, increasing complexity and furthering their end goal of making it harder to use external storage.

The fact is that letting apps access external storage in the form of a full filesystem means that data can flow freely between apps, just like on a regular desktop system you can create a file with one text editor and view it in another, or maybe the webbrowser if you're writing HTML, etc. You can put a negative spin on it with "apps could stomp on each other's data" or invoke the argument of "security" (which is already a solved problem: use a filesystem that supports permissions, like *nix always had), but there's no denying that it provides for seamless interoperability and sharing without any additional effort. It allows for the same level of flexibility that you would expect a general-purpose computer to have.

For example, I could plug in an SD card from a digital camera, open a file in one app to edit it, and then attach it to an email in another app, upload it to a cloud storage, etc. There's no additional "publish" or "import" steps required, only a way to choose the desired files in the filesystem to work on. Ditto for any other type of file, be it video, audio, text, etc.

Many people are now essentially carrying computers in their pockets which are orders of magnitude more powerful than desktop systems several decades ago, and yet what they can do with them is a shrinking subset of the functionality and generality those had. I think this is a massive step backwards.

Not really - ordinary users lost access to features they were using but power users still had access, albeit locked behind a terminal screen.

The only additional step on Android is you have to jump through whatever hoops was required for your device to get root, while Chromebooks have a 'get root' mechanism baked-in.

In both cases, Google's devs in certain departments aren't being pushed hard enough to put away the ping-pong paddles and stop playing foos-ball long enough to write some difficult code with a UI that has more than 3 steps. (Thanks Apple for dumbing everything down.)

Don't forget to star these issues.

At least on my main Linux box, the VFAT driver and USB3 driver collude to corrupt everything I store as FAT, so I've been using ext3 for my flash drives.

Actually I gave up on flash drives and just use Google Drive, but that is neither here nor there.

s/Succeeded/Consumed/g

It is nice to hear directly from users; something engineers thought was unimportant turns out to be a little more important than they thought. That's useful information.

Don't know what they use for their own filesystem though, I thought it was just ext4, but didn't find that anywhere.

On external devices however you'd probably want to "squash" the users (all files are effectively treated as owned by the one user; the user/person who inserted the external device) and also mount with noexec and nodev; don't allow the kernel to run any programs on external devices (avoid malware, hacks etc), and don't allow device files to be used on external devices (you don't want someone to put a crwxrwxrwx copy of /dev/kmem on an external device and allow someone to access it; then an unprivileged user can read all of kernel memory).

In stark contrast to the same style of comments provided by the chrome/chromium developers regarding two bugs / features identified on the GNU/Linux releases of same:

a) snap-back (move the scrollbar up or down, and then move your mouse more than 50px from the scrollbar, and it instantly flips the position back to where you started dragging -- a very MS-Windows experience), and

b) clicking in the URL / address bar automatically selects the entire address bar -- again, a very MS-Windows experience.

Both these features were added in chrome/chromium about 11 months back, were met with something between disdain and disgust, and though the developers said they heard the complaints loud and clear, discounted these concerns, as MS-Windows users preferred this MS-Windows-centric approach.

Bless.

(Yes, I'm still grumpy about all of the above.)

I have an Android phone because I like to be able to build small programs when I want without cost and when they removed SD Card write access it broke some usages I had. If it continues on this way I might as well buy an iPhone the next time.

I know it's a very specific case but in this case, some more common usages were broke as well (put the sd card from your camera in your tablet to organize/clean the pics, not possible anymore)

Unfortunately, although most of the "average consumers" are unlikely to become a developer, and "geeks" may be more likely to become developers, the fact is that most if not all developers start out as "average consumers" - regular users - so making it easy to stay a regular user and harder for "geeks" and developers also means fewer of the regular users will be inclined to take that next step up... end result being a reduction in the number of developers.

    mlabel -i <device> ::<label>

    e2label <device> <label>

I can't actually see where in the bug report it describes an issue that's specific to extfs?