- Feb 12, 2013
You've provided good information and (IMO) a reasonable bump. FYI, the developer is sometimes away from this thread for extended periods of time but is good about following up upon return.
I used to have the same problem and (a year and more ago) I started to use (there was a discussion about at that time) MiXPlorer builds with "API29" in the name (post #1, downloads)
Thanks., Now I can see the folders and files in it!I used to have the same problem and (a year and more ago) I started to use (there was a discussion about at that time) MiXPlorer builds with "API29" in the name (post #1, downloads)
That way, MiXPlorer can see and use /Android/data with no problem (probably even without root), on my two Xiaomi phones (one with MiUI 12.5/A11 and the other MIUI 13/A12) - screenshot
I can copy/paste between /Android/data and /Download, now I just played an ogg file I found in /Android/data/email/files and time ago I installed an apk attachment I found in the subfolder for another app there
First I uninstalled the previous MiX and then installed the api29.I can copy/paste between /Android/data and /Download, now I just played an ogg file I found in /Android/data/email/files and time ago I installed an apk attachment I found in the subfolder for another app there
Don't know if you need to enable some permissions for MiXPlorer in the native Settings for your ROM - A12 and.A13 might be tough about, and eg Xiaomi MIUI ROMs. Cannot help.you further
If you now installed that API29 MiX version, maybe you have two versions of MiX app installed and/or the new one did not install as update for your previous (they might have different package names), hence you maybe lost the permissions previously granted to MiX. You must investigate yourself
Have you checked the option in Magisk for Global Namespace? Settings>Superuser>Mount namespace Mode>Global
Warning, Rabbit Hole Ahead - Jumping in.
In other words this is looking to be a potential real issue or yet another challenge laid down by Google but it is hard to make sense of the information even though it is good information.
At the heart of it this is indeed a permissions error. It is not certain that the tips regarding resetting permissions will fix this but it seems applicable to run through them just to eliminate them. That being said, having tested some more I see evidence that this permissions landscape might have changed (perhaps more than once) since MiXplorer's developer was last here and since the last MiX beta.
Testing creation and editing of new text file in /android/data/com.google/android.video on external and internal storage on Android 11 stock moto rooted magisk in MiX XDA 6.58.5 (non API specific).
- In internal SD the file is created OK and after being edited and closed and reopened, it shows the results of the edit.
- In external SD card in the same folder structure the new text file is created but then when an attempt is made to edit it the result is the original file and a new file with "(1)" appended to the file name both of which have no contents. File can be created but no write permission to edit - has been reported before.
Here it gets weirder:
- A MiX log indicates that document providers have previously been configured for
/storage/emulated/0/[other non related folder out of this structure]
/storage/[external drive label]/
/storage/[external drive label]/Android/obb
/storage/[external drive label]/Android/data
Immediately, the document provider for the root of external storage stands out as an oddity because it is known that we are no longer allowed to assign document provider at the top level of the drive. How this got carried over from previous versions or added a new I do not know. Even more strange is that now, when following the routine to add document providers for those directories, on both internal and external storage after navigating in the native picker to the /android directory the only directory visible there is media.
It is possible that some MiXplorer settings got migrated over from previous android version on this device, and that is the only way I could explain the document provider for the root of external storage, but I definitely could see all the directories within /android on internal and external storage and was able to create document providers for them in the past. Other users have reported the closing of a loophole that allowed developers to work around scope storage. I wonder if this has been done within OS security updates or Google services from play store. This could explain the inconsistencies I see on my device and the differences in experiences regarding these permissions which don't run exclusively along the lines of different android versions.
Thanks for your answers.With this Scoped storage there is still some odd behaviour, I was having a play around and cannot delete or paste files into the root of android/data I get the file manager permission loop, I then tried copying a mp3 to the files folder of mixplorer silver, I could play it but it would not let me delete nor cut and paste it out of the folder, using the full root path I could though, think this is the same issue as that thing about deleting cached images that came up and I posted a log about, Hootan who I hope is well will need to have a look to iron some of these issues with the android/ folders out @dari-woka try and play your video, copy/paste by using the full root path to see what happens
Should also say I am on android 13 and using a Pixel 4a, will try and get a log posted
Yeah having a problem copying the logs from android/data/mix sliver although going through full root works
Error trying to delete the mp3
181 I/MiX> ----- Operation started ----------------------
182 I/MiX> Action: DELETE
183 I/OPERATION> #1 DELETE /storage/emulated/0/Android/data/com.mixplorer.silver/files/A Fistfull of dollars .mp3
184 D/DOC> DOC null!!
185 D/COUNT> Total: 1
186 I/OPERATION> #1 DELETE -------
187 D/STORE_REMOVE> Remove media /storage/emulated/0/Android/data/com.mixplorer.silver/files/A Fistfull of dollars .mp3
188 I/MiX> No item deleted
189 I/MiX> ----- Operation finished. 0s -------------
196 I/MiX> ----- Operation started ----------------------
197 I/MiX> Action: COPY
198 D/COUNT> Total: 15233 bytes
199 I/OPERATION> #1 COPY ---------------------------------------
200 D/OH:> default
201 W/SDExplorer> NULL or Dst 15633 != Src 15233 > /storage/emulated/0/MiX-B22090810_2022-12-05_19-34.txt
202 I/OPERATION> #1 COPY -------
203 I/MiX> No item copied
204 I/MiX> ----- Operation finished. 0s -------------
About the location of folders, can't see what problems would be caused by nesting a folder, its still part of the root of internal storage, unticking the Data in root option just moves the folder back into the app's data folder, why cant the recycle folder be treated the same? both folders are only used by mixplorer, pet peeve of mine is how messy internal storage gets, anyway to keep it nice and tidy and I am in.
The big massive button REMOVE ALL ..... that I completely missed, Time to book an opticians appointment and get the headlamps tested.At the bottom of the undo pop up menu is a button to "remove all".
As to Dotfolders, +1 to any size limit settings or size or time reminders that could be added to the recycle bin feature without bloating the app but...
although I understand the desire to limit the number of DOT folders in the root of internal and external storage, those folders allow us to work around some of Google's restrictions, and they serve different purposes, and they can be toggled on or off independently. It may not be wise to put the .recycle folder within another folder which serves a different purpose and could be disabled or deleted, or to put it in a location that non-rooted users cannot access. Some users may use the recycle bin but may never need the .mixplorer folder, and for other users it may be the other way around.
Another consideration is that the universe of android OS variability regarding file management is bigger and more variable (that is to say sloppy and inconsistent) than that of windows, ios, or Linux which do things to keep the inner workings of recycle and trash bins out of sight and protected. On android some of these workarounds with DOT folders maybe the only way to achieve some of these things, such as a recycle bin, in the messy Android universe.
In a way the purpose served by these additional folders is to do what you suggest, to create "a place for everything and everything in its place".
In any event, again +1 to any possible enhancements of the presentation possible undo actions, but for the moment, considering the significant changes recently made it might be a good idea for people to explore the functionality of the feature including all available options and buttons, and to confirm that the undo operations are actually successful.
It's not just about the Trash bin.Now the word "Trash" is gone so what will Mac users do?
But seriously, even though I agree with the change in terminology the new label is so long as to undermine itself as a label.
@HootanParsa, here is a suggestion which might accommodate all user preferences while making the label shorter by renaming it to the following:
Recycle (also known as Undo or Trash).
- 'Remember Delete option' will remember the last selected option in dialog.@m0han Ninja-ed me but, maybe Undo is not quite all back. Not posting as implied criticism, I've been on a deep dive into the Rabbit Hole this Evening (or Morning or Afternoon) and just came up for air after a few hours so here we go.
6.59.0-BETA B23012410, Stock Moto A10 rooted magisk, testing with files on external SD. Settings > More settings, now includes all 3 options: Recycle bin, Undo, and Remember delete but, I’m not seeing how to use them properly or there are still issues with them. Details below;
- With only Recycle Bin enabled then recycled files are sent to the .recycle folder and can be restored manually but there is no apparent option in the menu. The deleted files in the .recycle folder retain their original names but without something like the menu that was used for the old undo function, a user would have to know the file name and search for it or search for all files in the .recycle folder to find the item to restore.
- With only Undo enabled then after copy or move (or delete) operations, there is a Menu > undo item but invoking it yields toast “no item”.
- With both Recycle Bin and Undo enabled, then the same as above: after copy or move or delete operations, there is a Menu > undo item but invoking it yields toast “no item”.
- The .recycle folder (when not deleted between tests) seems to contain the files that were deleted with Recycle Bin enabled, and also seems to contain the folders for the copy/moves (although those folders contain no identifiable files.
- With both Recycle Bin and Undo disabled, a file that is Deleted via Select > menu > tap delete > acknowledge permanent = is actually deleted and does not force the creation of the. recycle folder. That is good but…
- Now we get to the drum I may beat until the skin on my hand or the skin of the drum starts to crack. With both Recycle Bin and Undo disabled, Select > long press deletes still creates the .recycle folder and copies the file there. I don’t care what is done with the Recycle Bin because I don’t use it and that it sort the point. I dont use it but it still can happen. Even with all relevant options disabled it is all too easy for an intended delete operation to become a file copy operation into it another folder unbeknownst to the user and not with the scope of familiar locations where it might be discovered. Please give us a way to disable this.
Remember delete option remained disabled throughout testing.
.recycle folder was deleted between major test segments,
BTW @HootanParsa, assuming that both Beta and XDA version might be using the .recycle folder, are there any concerns for people who use Recycle Bin in multiple version of MiX (XDA, Silver, Beta)? This is not of concern to me as I only Recycle Bin in the beta for testing (so there is nothing potentially placed there by the XDA version is at risk) but I was curious about this.
More annoying than people who can't read a few pages back in a thread, or maybe even search the thread which would lead you to your answer and/or the amazing MiXplorer thread by @IronTechmonkey that has loads of useful info. Just like what you were asking about.