The file length is 0 when you recreate the file from the URI or the original file path [getExternalFilesDir (line type) vs getFilesDir ()]

Question

A bit of background: this app takes a picture and loads into the Blade Azure repository.

The image is saved in a file (internal storage) using getApplicationContext().getFilesDir();

To download, I need to call the uploadFromFile (..) function as follows: CloudBlockBlob.uploadFromFile(String path);

The Azure SDK uploadFromFile function is as follows:

 public void uploadFromFile(final String path) throws StorageException, IOException { uploadFromFile(path, null /* accessCondition */, null /* options */, null /* opContext */); } public void uploadFromFile(final String path, final AccessCondition accessCondition, BlobRequestOptions options, OperationContext opContext) throws StorageException, IOException { File file = new File(path); long fileLength = file.length(); InputStream inputStream = new BufferedInputStream(new FileInputStream(file)); this.upload(inputStream, fileLength, accessCondition, options, opContext); inputStream.close(); } 

The problem is in the line long fileLength = file.length(); where the file length is 0.

I tested this against using Environment.getExternalStoragePublicDirectory(Environment.DIRECTORY_PICTURES); for the repository directory. It works.

I need to use internal storage and external storage, as this is necessary for this project.

EDIT: File mPhotoFile's documentation for the intent of my camera. It will contain a photo. mPhotoFileUri contains the URI for this file. Below is the code for using the path from the file.

 File file = new File(mPhotoFile.getPath()); // value -> /data/user/0/com.example.devpactapp/files/JPEG_20160209_234929_1936823724.jpg boolean fileExists = file.exists(); // true long fileLength = file.length(); // length 0 

Below is the code to get the file from the URI.

 File file = new File(mPhotoFileUri.getPath()); // value -> /data/user/0/com.example.devpactapp/files/JPEG_20160209_235534_-1059496729.jpg boolean fileExists = file.exists(); // true long fileLength = file.length(); // length 0 

I need to pass the path of this file to the uploadFromFile function.

The workaround mentioned in my "answer".

Answer 1

Even if I do not have all the information, I will make a call that the file is not in the path you specified. javadoc for length () specifically mentions that this case will return 0.

So, try checking exists () before doing anything with the file.

Answer 2

When using internal storage, the file path is different. I think it is stored in / storage / emulated on recent devices. Check the file path. and see if you are creating a file with an absolute path.

Answer 3

Workaround detected. This is the function I used to get the file that was transferred to the camera’s intent.

  // Create a File object for storing the photo private File createImageFile() throws IOException { // Create an image file name String timeStamp = new SimpleDateFormat("yyyyMMdd_HHmmss").format(new Date()); String imageFileName = "JPEG_" + timeStamp + "_"; File storageDir = getApplicationContext().getFilesDir(); mPhotoFileExists = true; // check if access to external storage exists // if returned true, return the new file // if returned false, user could have been requested for access // so, need to check if permission is available now // if still not available, return null if(haveWritePermissions()) return File.createTempFile( imageFileName, /* prefix */ ".jpg", /* suffix */ storageDir /* directory */ ); return null; } 

I changed storageDir from getApplicationContext().getFilesDir(); on getApplicationContext.getExternalFilesDir(null);

Docs: getExternalFilesDir (string type) , getFilesDir ()

I went null , because I did not want to set Environment.DIRECTORY_PICTURES , which would allow Media Scanner to find the image file.

I understand that this is in no way a “fix”. Still looking for an answer on why getFilesDir () is causing this problem.

EDIT: A very pressing reason why this is not a good solution - external storage is not always available, in which case there would be no workaround. In addition, here you can write any other application with permission WRITE_EXTERNAL_STORAGE . Therefore, security is not ensured.