Closed fm-sys closed 2 years ago
I have an idea what the source of this bug might be: the upfront checks whether the default folders are accessible might be a little too "successful" here...
Jupp, guessed right. This is happening because at startup c:geo checks for all folders whether their default is accessible (and when doing that it creates said default folders).
This is not easy to solve, the default folder check must be moved to the time it is first needed. Something for a long winter night with no other c:geo issues lying around...
What happens if we (one day) plainly remove the legacy file access permissions?
What happens if we (one day) plainly remove the legacy file access permissions?
Then the problem will be gone.
I also have to add that I am almost completely sure that the problem will only happen on Android <= 10, not in Android 11 any more. Because the default file creation process should simply not work there (which is then handled correctly by c:geo, don't worry). It is actually the "trying whether we could reach the folder" which currently results in the unwanted creation of the folder. (Note: have to admit that this is all guess-work by now after looking into code, haven't tested this for real yet)
Might be solved implicitly by #11791. Should be retested as soon as the PR is merged...
Yes, is indeed fixed. Thanks @eddiemuc for improving the startup performance and (implicitly) fixing this issue 👍
Describe your problem!
I have just set my cgeo base folder to
emulated/0/Locus
as many files are needed for both apps.However, although I have deleted the old "cgeo" base folder it gets always recreated when I start cgeo, which pollutes the storage without any value...
How to reproduce?
cgeo
Actual result after these steps?
No response
Expected result after these steps?
No response
Reproducible
Unclear
c:geo Version
Current nightly
System information
Additional Information