Android: disambiguating file paths

2020-07-06 02:53发布

In my app, users pick files. Internally, I store information about the file, which I key based on the file path. Next time that file is used, I do stuff with the stored information. Trouble is I instantiate my files with:

File file1 = new File(Environment.getExternalStorageDirectory() + "/test.txt");

And then, on a particular JB device, file1.getCanonicalPath() gives: "/storage/emulated/0/test.txt".

The trouble is that when other apps launch my app with a file path in an Intent, the paths they send tend to look like: "/mnt/sdcard/test.txt".

Is there a smart strategy to disambiguate these two paths? Possibly I should be instantiating my files differently?

Edit:

The trouble is, the two canaonical paths for the two files are not equal. For the below, cp1=="mnt/sdcard/test/txt" and cp2=="/storage/emulated/0/text/txt":

File file1 = new File("/mnt/sdcard/test.txt");
File file2 = new File("/storage/emulated/0/test.txt");

String cp1 = file1.getCanonicalPath();
String cp2 = file2.getCanonicalPath();

标签: android
4条回答
ゆ 、 Hurt°
2楼-- · 2020-07-06 03:37

Take a look at the answer here. It also uses canonical path, but in a slightly different manner that might work for you

查看更多
走好不送
3楼-- · 2020-07-06 03:39

First, the only correct way to get the external path is using the getExternalStorageDirectory and other getExternalStorageXXX in Android.

Android will firstly try to resolve two system variable:

String rawExternalStorage = System.getenv(ENV_EXTERNAL_STORAGE);
String rawEmulatedStorageTarget = System.getenv(ENV_EMULATED_STORAGE_TARGET);

while the ENV_EXTERNAL_STORAGE = "EXTERNAL_STORAGE" and ENV_EMULATED_STORAGE_TARGET = "EMULATED_STORAGE_TARGET". If the EMULATED_STORAGE_TARGET variable is set, it means the device has emulated storage then the storage path will be EMULATED_STORAGE_TARGET.(After Android 4.2, it support multiple-user external storage, then there would be a /0 or 0 after the path) But if it is not set and EXTERNAL_STORAGE is set, the path will be EXTERNAL_STORAGE. If both of them are not set, the path will be /storage/sdcard0 by default. So different devices may contain different paths for external storage.

As External Storage Technical Information says, you can customize the storage of the device by setting up the init.rc file. For example in the default goldfish one:

export EXTERNAL_STORAGE /mnt/sdcard
mkdir /mnt/sdcard 0000 system system
symlink /mnt/sdcard /sdcard

If you use getExternalStorageDirectory you will get /mnt/sdcard, but /sdcard is a symbolic link to that directory.

So in your case, the init.rc may contain:

export EMULATED_STORAGE_TARGET /storage/emulated
symlink /storage/emulated/0 /mnt/sdcard

So they are not ambiguous, they are actually same.

I think the getCanonicalPath() might work for the vast majority of your use cases.

A canonical pathname is both absolute and unique. The precise definition of canonical form is system-dependent. This method first converts this pathname to absolute form if necessary, as if by invoking the getAbsolutePath() method, and then maps it to its unique form in a system-dependent way. This typically involves removing redundant names such as "." and ".." from the pathname, resolving symbolic links (on UNIX platforms), and converting drive letters to a standard case (on Microsoft Windows platforms).

Every pathname that denotes an existing file or directory has a unique canonical form. Every pathname that denotes a nonexistent file or directory also has a unique canonical form. The canonical form of the pathname of a nonexistent file or directory may be different from the canonical form of the same pathname after the file or directory is created. Similarly, the canonical form of the pathname of an existing file or directory may be different from the canonical form of the same pathname after the file or directory is deleted.

查看更多
神经病院院长
4楼-- · 2020-07-06 03:43

There is probably no easy solution for this. The problem is that apparently there are two different mount points in the file system that actually point to the same location. File.getCanonicalPath() can only resolve symbolic links but not different mount points.

For example on my Nexus 4 this code:

File file1 = new File(Environment.getExternalStorageDirectory() + "/Android");
System.out.println("file 1: " + file1.getCanonicalPath());
File file2 = new File("/sdcard/Android");
System.out.println("file 2: " + file2.getCanonicalPath());

prints

file 1: /storage/emulated/0/Android
file 2: /storage/emulated/legacy/Android

I used this code to exec "mount" and print the output:

Process exec = Runtime.getRuntime().exec("mount");
InputStream in = exec.getInputStream();
BufferedReader br = new BufferedReader(new InputStreamReader(in));
while (true) {
    String line = br.readLine();
    if (line == null)
        break;
    System.out.println(line);
}
in.close();

The relevant output is:

/dev/fuse /storage/emulated/0 fuse rw,nosuid,nodev,relatime,user_id=1023,group_id=1023,default_permissions,allow_other 0 0
/dev/fuse /storage/emulated/legacy fuse rw,nosuid,nodev,relatime,user_id=1023,group_id=1023,default_permissions,allow_other 0 0
查看更多
做个烂人
5楼-- · 2020-07-06 03:47

On newer Android versions, SD storage is available from many paths, for example:

/storage/emulated/0
/storage/emulated/legacy (root account most of the time)
/sdcard
/data/media

If you check on which device those paths are located, some are on different devices (because of fuse 'virtual' filesystem), hence getting their canonical path doesn't lead to the same file path, even though they are actually the same files.

Furthermore, it appears that on Marshmallow, things get worse and even file path under /sys (full of redirections/links) are not reported properly and getCanonicalPath() returns the original path instead of actual canonical path.

While a ls -l (or readlink) on the given file path will show the actual canonical path, the API doesn't work anymore. Unfortunately running a readlink or ls -l is very slow (average of 130ms when the shell is already running), compared to an already slow, but much faster getCanonicalPath(), it's a pity.

Conclusion, getCanonicalPath is broken and has always been broken.

查看更多
登录 后发表回答