5

From what I guess, internal storage is available by every user. If emulated storage is a storage location, made for a specific user, are files created in /storage/emulated/0 supposed to appear in /storage/sdcard0? I assume no, because files that are user created should show up in emulated only, otherwise files created by the user would be available for all other users to see.

  • What makes you think /storage/emulated/0 is specific to a given user – and not just the "first emulated storage device", as /storage/sdcard0 is the first (internal) SD card? – Izzy Apr 27 '17 at 16:16
  • @Izzy Because the numbering (i.e., in this case '0') indicates a storage space allocated for a specific user. Didn't Android become a multi-user platform as of Android 4.2? – Narcotixs Apr 27 '17 at 16:22
  • 1
    @Narcotixs The directories are linked to the same physical location, which is normal. – Dan Brown Apr 27 '17 at 17:43
  • 1
    @DanBrown If I got this right, the OP is asking: "If /storage/sdcard0 is freely readable and writable, what's the point of having a /storage/emulated/X directory for each user?", which is a good question. – Death Mask Salesman Apr 27 '17 at 18:06
  • 1
    @DanBrown no need for root, you can use a terminal without :) And yeah, my guess seems correct: Why does Android use fuse for internal SD card mount? says The FUSE filesystem also manages permissions for the files stored in the /data/media folder. Let's see if I can find some more evidence that justifies an answer :) – Izzy Apr 27 '17 at 21:40
6

I've checked on one of my devices, and as the comment chain already suspected, you don't need to worry about everyone having access to everybody elses data. First:

/storage/sdcard0 -> /storage/emulated/legacy

Which means, it's just a symlink which always points to the data of the current user:

/storage/emulated/legacy -> /mnt/shell/emulated/0

(the first user – in my case the only one). Second, where you usually look for it:

/sdcard -> /storage/emulated/legacy

Same game again. So for the emulated SD card (aka the "internal SD card), the Android system takes care to map it accordingly for the current user. Not sure about the external SD card (if that e.g. could be used to share data between multiple users). This is usually found in /storage/sdcard1:

$ mount | grep sdcard
/dev/block/vold/179:65 /mnt/media_rw/sdcard1 vfat […]
/dev/fuse /storage/sdcard1 fuse […]
$ ls /mnt/media_rw/sdcard1
/mnt/media_rw/sdcard1: Permission denied
$ su -c "ls /mnt/media_rw/sdcard1"
[data from external SD card]

So you can see the external SD card can only be accessed directly with root powers, why "ordinary users" have to go via a FUSE mount overlayed on that. So the system again might take care that each user can only access his/her own data in that place. I'm not familiar enough with the internals to say for sure (or even to say what exactly is done there).

Now for your explicit question, whether files created in /storage/emulated/0 supposed to appear in /storage/sdcard0: Assuming you're speaking about /mnt/shell/emulated/0 (I couldn't find /storage/emulated/0 on my device), empirically they of course do, as both are the very same location: /storage/sdcard0 -> /storage/emulated/legacy -> /mnt/shell/emulated/0 – which means that /storage/sdcard0 shows what's contained in /mnt/shell/emulated/0. But your concern is unwarranted: due to the "middle-man" (/storage/emulated/legacy), /storage/sdcard0 always points to the storage of the "logged-in user" – so if e.g. the second user looks there, (s)he will see what's in /mnt/shell/emulated/1 (or which ever his/her emulated storage area is).


So as a PS, let me sum up things from the comments, as a short FAQ:

  • I wonder what would happen if a different user tries to access and save data in a different user's emulated storage?
    He receives an error message that it's either not there or not accessible.
  • Why are these symlinks needed?
    Multiple reasons, many of them historical (one word: "compatibility").
  • What are those symlinks and how do they work, in laymens terms?
    They are basically "signposts", saying "please look there". Other than you initially assumed, they don't contain any data themselves – they are really only signposts or "pointers". The data itself resides at the "targeted location", and only there. For more details, please see the Wikipedia article on symbolic links.

Also see:

  • This may be off-topic slightly, but why are these symlinks needed? What was the reason why the storage architecture was changed and designed to what it is now? – Narcotixs Apr 27 '17 at 23:39
  • Why does "/storage/sdcard0" point to "/storage/emulated/legacy"? I thought emulated storage should always point to the original storage location (i.e., internal storage or the real virtual storage location) or is there no pointing at all, that it is just a mutual bidirectional reference towards each other? – Narcotixs Apr 28 '17 at 5:31
  • Sorry, I cannot answer that. Maybe you ask it as a separate question? Also, if this answers your original question, consider accepting it, @Narcotixs ;) And sorry for having rejected your edit: your change doesn't reflect what I found; /sdcard here is a direct link to /storage/emulated/legacy, not to /storage/sdcard0. – Izzy Apr 28 '17 at 7:00
  • 1
    Symlinks are unidirectional, some kind of "redirects" (aka "look there"). But as such, if you'd create a file at /storage/emulated/0, it would of course show up in /storage/sdcard0, as in both are pointing to the very same place. Oh, I see, I should have written that explicitly – that's the problem if you work with a thing every day, it's clear that a symlink does that :) OK, will add that to my answer. – Izzy Apr 28 '17 at 7:15
  • 1
    You again turned the horse around, which causes your confusion ("why does it have its head at the wrong end?"). It's not /storage/emulated/* pointing to /storage/sdcard0 but the other way around. So if "user0" is logged in, sdcard0 points to emulated/0 but if "user1" is logged in it points to emulated/1 – i.e. "the sdcard" always points to the emulated storage area dedicated to the logged-in user – which of course holds different content for each user. – Izzy Apr 29 '17 at 9:36
0

Mr Expensive Toys said: Am amazed that this problem is still showing up as it started happening as far back as Honeycomb.

So, the /storage/emulated/0/DCIM/Camera is the same folder as your normal DCIM/Camera folder. Its just a symlink. So the files are actually in the right location you just have an app that put bad data into the MediaStore Database.

When accessing files from your PC your are actually enumerating the MediaStorage database for files. Its not pulling a traditional directory lists. So what you see is based on what is in that database and the path entries in the database.

Files in the database pointing to emulated directories aren't shown as they are assumed to be duplicates as its the same physical directory as your normal DCIM/Camera. What is going on is that some poorly written third party apps are inserting entries into the database with the /storage/emulated/0/DCIM/Camera path instead of the proper root path to DCIM/Camera. Which means that the MTP service can't see them when you are hooked up to your PC.

Usually the easiest way to fix the problem is to just clear the MediaStore databases to get the bad entries out of the MediaStore Database and let the system reindex the files and put into the database with the proper paths.

Settings->apps Hit 3 dot menu in top right and select Show System Find Media Storage, Select it, Select Storage, then Clear Data Find External Storage, Select it , Select Storage, then Clear Data Turn phone off, turn phone back on, wait for indexer service to rebuild the data.

When you are done the files should show up with proper directory tree and be visible from the PC. Depending on amount of files on the phone it can take as 10-20 minutes to rebuild the media database as the service walks the phone directories, getting meta data, creating thumbnails, etc.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.