In Progress
Status Update
Comments
do...@gmail.com <do...@gmail.com> #2
I just noticed that in Sequence 2, no Media Store Update event is being triggered. That might or might not be intended in this case, but it's worth noting. Might DFE have another right-click option of "trigger media store update event" next to "Synchronize"?
uc...@google.com <uc...@google.com>
es...@google.com <es...@google.com>
ro...@google.com <ro...@google.com>
ro...@google.com <ro...@google.com>
ro...@google.com <ro...@google.com> #3
A fix has been checked in for sequence 1 (not collapsing file trees on synchronize) and will appear in a future release of Android Studio.
Description
AI-191.8026.42.35.5791312, JRE 1.8.0_202-release-1483-b03x64 JetBrains s.r.o, OS Windows 10(amd64) v10.0 , screens 1920x1080
AS: 3.5; Android Gradle Plugin: 3.5.0; Gradle: 5.4.1; NDK: from local.properties: (not specified), latest from SDK: (not found); LLDB: pinned revision 3.1 not found, latest from SDK: (package not found); CMake: from local.properties: (not specified), latest from SDK: (not found), from PATH: (not found)
IMPORTANT: Please read
Repro: On Android P emulator (no Google Store, but it's not relevant). Connected via adb to a PC (Windows PC, although I doubt it matters what PC). In my case that's a direct in-memory connection.
Tools:
1) An app running on the emulator that can be triggered to remove a directory (recursively) (in sdcard a.k.a storage/emulated/0/ and several other things.) Let's do this in the Android default "Download" directory. (This may or may not occur with a privileged file manager; I was testing with an app that was NOT privileged.)
2) on the PC, a directory that contains several files. AFAICT it doesn't really matter what, but non-empty but small files is what I tested with. (Call this "source")
Sequence 1:
Open Download in Device File Explorer (DFE). There should be no directory "source" visible. Right click "Download", click 'Upload' and find and upload "source" on the PC (via the PC filesystem search window Device File Explorer opens).
The view of Download will refresh now showing "source".
Use the app to remove "source". Note that nothing changes in DFE window.
Right-click Download, and click 'Synchronize'. Note that the file tree is now completely collapsed.
Reopen Download, and note that "source" is gone.
Expected Result: The file tree is NOT collapsed when 'Synchronize' is clicked, so it's not necessary to click several times to
get back where you were to see the result.
Hoped for Result: that the change made by the app is immediately visible, rather than having to 'Synchronize' at all. (I realize this might be harder, given the need for 'Synchronize' at all, but I can hope... The fix for Sequence 2 may be closely related)
Sequence 2:
Open Download and Upload "source" as above.
Delete "source" using DFE.
Repeat once, just to be sure. Note there should be no problems doing this. Note that DFE remembers the last file/directory you uploaded, so you can just click through. (Do that for this repro.)
At this point, "source" is not present on the Android file system.
Using Windows File Explorer, change the name of one of the files in "source" on the PC.
Upload as above.
Result:
1) An error similar to this is reported:
4:00 PM Device File Explorer
There were errors uploading files and/or directories, although 7 files were successfully uploaded in 623 ms for a total of size of 2,333,694 bytes:
Local path doesn't exist.
2) The renamed file is not present in the uploaded copy of "source" but the old file (name and content) is present. (Note: neither the Android filesystem nor the PC have the old name at the moment the upload is started, yet it is being remembered somewhere!)
Expected Result:
The upload with the new file name is successful, just as it was the first and second time. Note: if you click around enough, the upload will finally succeed when you try it.
I've seen other strange behaviors in DFE, all of which appear to be related to some sort of cache that it's keeping, and the likelihood is that it's not invalidating/refreshing when it needs to.
I don't have further repeatable sequences figured out, but I've seen other incorrect behaviors that appear to have the same underlying cause.