
Decision to drop ext support from ChromeOS Files.app reversed due to outcry - soundsop
https://code.google.com/p/chromium/issues/detail?id=315401#c124
======
antman
"Thanks for all of your feedback on this bug. We’ve heard you loud and clear."

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](https://code.google.com/p/android/issues/detail?id=67570)

~~~
fpgeek
While frustrating, the SD card situation is very different.

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.

~~~
userbinator
If the problems were so "serious" I wonder how people ever managed to use
external storage on their computers, long before Android even existed...?

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.

------
krakensden
It's really heartening to see a response from a user experience team to "you
broke my workflow" that isn't "get fucked". I'd basically found forgotten that
was a possibility.

------
lnanek2
Google has been working hard to break compatibility in a lot of places, like
XMPP and calendars. They just don't care about interop and want to lock people
in. Pretty sad coming from a company that made fun of Microsoft on stage at
Google IO for breaking interop. It is sort of like a person who litters and
creates an obnoxious environment to live in complaining the other people gets
to litter more than them.

------
higherpurpose
Wasn't the outcry mainly because of a misunderstanding - thinking Google is
dropping support for ext4 for _internal_ storage, when in fact it was dropping
for _external_ storage? (microSD, etc)?

~~~
jrockway
No. I don't think anyone cares what the internal storage uses; that's just an
implementation detail. People want to connect random drives to their ChromeOS
machine and have them Just Work, which is quite reasonable.

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.

------
Fastidious
Slightly on topic. I thought OS X was the only OS the named their applications
Something.app. ChromeOS does it too?

~~~
pjmlp
Something.app comes from NeXTStep actually.

~~~
Fastidious
Succeeded by OS X.

~~~
djtriptych
s/Succeeded/Consumed/

~~~
malkia
you forgot the g

s/Succeeded/Consumed/g

------
juanbyrge
I bet with these types of fiascos, Google will be less likely to publish the
source code of their projects in the future. When an uproar like this happens,
it's impossible to engage in a technical discussion and find compromise.
Sometimes fewer features make a better product.

~~~
jrockway
Flamewars are nothing new on the chromium.org issue tracker. Pretty much every
bug looks like this one. Ultimately, the transparency and ability to accept
external contributors outweighs the effort required to mitigate the flamewar.

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.

------
muyuu
This thread got big in r/linux
[http://www.reddit.com/r/linux/comments/2iyplo/chromeos_will_...](http://www.reddit.com/r/linux/comments/2iyplo/chromeos_will_no_longer_support_ext234_on/)

------
sklogic
Lack of NFS support in chromeos kernels is also extremely annoying.

~~~
juanbyrge
Lol, nobody uses NFS except lunix tools.

~~~
sklogic
The problem is, if you install chrubuntu, you have to share the same kernel
with chromeos. Why did not they build an NFS module?

------
morsch
What's the native filesystem on a ChromeOS device? FAT32? That can't be right.

~~~
onli
They dropped support only for external devices. See
[https://news.ycombinator.com/item?id=8444603](https://news.ycombinator.com/item?id=8444603).

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

~~~
tankenmate
They need a filesystem that can support the notion of users; very little of
the software on ChromeOS runs as root for security reasons. FAT doesn't
support the notion of file permissions on a user basis; so it would be
insecure. ext4 is the most widely used and tested Linux filesystem at the
moment. Therefor the least effort filesystem to use for your root filesystem
is ext4.

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).

------
Jedd
"Thanks for all of your feedback on this bug. We’ve heard you loud and clear."

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.)

~~~
jessaustin
It has been years since I used Windows more than once a month, but a) seems
like a convenient feature, while I'm pretty ambivalent about b).

------
andymoe
This is actually too bad. These kind of decisions, compounded, is why Googles
stuff is arguably so much less usable for the average Joe/Jane than Apple and
why their ecosystem is such a mess for developers to work with. They don't
have the will be ruthless and cut features at the expense of geeks like me in
order to make the system more usable for the average consumer.

~~~
andymoe
Oh so much disagreement with me on this. Oh well, down-vote away... Did you
all read the ticket and the initial reasoning for dropping support for the
file format on the _external_ memory card? It was so they could support
renaming it more easily. I'm not saying I don't care about the file format
(actually I don't) what I'm saying generally is that usability should trump
most everything else and Google gets it wrong again and again.

~~~
vertex-four
Renaming a FAT filesystem:

    
    
        mlabel -i <device> ::<label>
    

Renaming an ext filesystem:

    
    
        e2label <device> <label>
    

You can detect whether it's one or the other in the mount table. It amounts to
maybe a dozen lines of bash code at maximum - maybe a few more if it's C++,
depending on what abstractions already exist.

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

