Trevor, could you identify an owner in the Files app team?

This is needed for M69 for camera-gallery integration work. When the user clicks on the thumbnail of recent captured photo which is deleted and Files hasn't notified camera to do whole directory scan, it will open gallery and gallery will generate the 0 byte file. After that, all the following directory scan would think that the file exists, and therefore the thumbnail in the camera would persist and lead to the broken gallery screen when clicked. 

While this is not a common scenario that will be triggered frequently, the generated 0 byte files will always be there even if the bug gets fixed in future releases. That's why I think fixing it in M69 is necessary.

I'm pretty unfamiliar with all this code, but I think the problem starts here:

https://cs.chromium.org/chromium/src/chrome/browser/chromeos/file_manager/fileapi_util.cc?q=FileSystemContext::RESOLVED_ENTRY_NOT_FOUND&sq=package:chromium&g=0&l=189

if ResolveURL() returns storage::FileSystemContext::RESOLVED_ENTRY_NOT_FOUND we set `error = base::File::FILE_OK` and just continue. There's no way to later distinguish a file that doesn't exist from one that should be created.


  switch (type) {
    case storage::FileSystemContext::RESOLVED_ENTRY_FILE:
      entry_definition.is_directory = false;
      break;
    case storage::FileSystemContext::RESOLVED_ENTRY_DIRECTORY:
      entry_definition.is_directory = true;
      break;
    case storage::FileSystemContext::RESOLVED_ENTRY_NOT_FOUND:
      entry_definition.is_directory = iterator->is_directory;
      break;
  }
  entry_definition.error = base::File::FILE_OK;


this is from https://codereview.chromium.org/296693003 . But, before that, there was no handler for RESOLVED_ENTRY_NOT_FOUND at all.

Perhaps either EntryDefinition needs an "exists" property, or EntryProperties does.

I don't think ResolveURL is relevant here (though having "exists" property may be helpful in some cases.)
Having an entry for non-existent path is a valid usage.

~~~~
+the current files.app owners


When a non-existent path is passed to a Chrome app with filesystem-writable permission,
an empty file is created and then passed to the app. The behavior dates back to
https://chromiumcodereview.appspot.com/10534156


The original code above was for the case when the app invoked the "save-as" dialog.
One thing on which we may be able to post a question is that the same "CheckWritable" logic
(which was renamed to "PrepareWritableFile" at some point) also takes place when the app
is launched with a file path as an argument.

https://chromium.googlesource.com/chromium/src/+/3dd38fabc2b2f8b6f99af90972b8270e2b500c26/apps/launcher.cc#218

My quick guess is that this is the point where the 0-byte file is created.


It may be a possible option to make the case (non-exist path as launch argument) an error... compared to
a non-existent path returned from save-as dialog, the former situation does not sound making more sense.
But I'm not fully sure if it's really fine compatibility-wise.

omrilio@ - Is there a workaround for M69? I don't think we have someone on the Files team who would be available to look at this in this timeframe.

Issue 867705 for another chrome.fileManagerPrivate.executeTask. +Trent here as an FYI, since he toured that code in detail recently reading issue 867705.

P3 from the files app perspective.  If the Camera app allows used to open a file in FilesApp, and user deletes that file while in FilesApp, then ...

> When the user clicks on the thumbnail of recent captured photo which is deleted and Files hasn't notified camera to do whole directory scan

@shenghao

How would Files app notify you?  Could you use chrome.fileSystemProvider to watch for the directory/file changes yourself?

Re #10,
We are using chrome.fileSystemProvider to be notified of file changes.