Xamarin-android: System.UnauthorizedAccessException: Access to the path is denied. ---> System.IO.IOException: Operation not permitted

[Golemanova]

Steps to Reproduce

1. Create a Xamarin project for Android
2. Ask for ReadExternalStorage and WriteExternalStorage permissions
3. Try simple operation using System.IO.File like Copy or Move

Sample code

        try
        {
            string logFolder = Path.Combine(Android.OS.Environment.ExternalStorageDirectory.AbsolutePath, "Download", "logs");

            DateTime now = DateTime.Now;
            string timestamp = now.ToString("yyyyMMdd_HHmmss");
            logFolder = Path.Combine(logFolder, timestamp);
           Directory.CreateDirectory(logFolder);

            foreach (var logFile in _logFiles)
            {
                string destFilePath = Path.Combine(logFolder, _systemIo.GetName(logFile));
                File.Copy((logFile, destFilePath);  //File.Move results in the same error
            }
        }
        catch (Exception ex)  {  }

Expected Behavior

Step 3 to be executed successfully

Actual Behavior

System.UnauthorizedAccessException: Access to the path is denied. ---> System.IO.IOException: Operation not permitted

Sometimes for the same code, I get System.IO.IOException: Sharing violation on path /data/user/0/com.my.project/files/logs/20190801.log

Worked without problem with XamarinAndroid SDK 9.1 and VS 2017

Version Information

[MariqAt]

I have the same issue. It is also for Xamarin.Android 9.5.

[tobiasschulz]

We've got this issue too, for example on a Galaxy S6, but not on other devices.

[grendello]

@Golemanova would you mind attaching a self-contained, small application that reproduces the issue? It might be a number of things (most of which would be unrelated to Xamarin.Android) and I'd like to test the exact project that gives you problems (some issues might be caused by settings in .csproj or AndroidManifest.xml), thanks!

[tobiasschulz]

We are having this issue with about 5% of our customers. It happens pretty often on a Samsung Galaxy S6 (SM-G920F).

But I don't think it's that easy to reproduce. It doesn't seem to happen after the app is started, but some time later.

But seriously, Microsoft breaks stuff like this, and we are supposed to spend time and money to reproduce the issue?

[Golemanova]

@grendello I cannot provide you with the exact project that is causing the issues.
Everything was working fine until we upgraded to Xamarin 9.4 which we did because we needed to create an app bundle.

The bug is easily reproduced, it happens every time File.Copy or File.Move is used. With the File.Copy I also get System.IO.IOException: Sharing violation on path /data/user/0/com.my.project/files/logs/20190801.log although I have asked the user the required permissions.

The project is active for two years now and we didn't have any of these issues before the update.

[kvpt]

The issue is probably from the mono side.
This issue seems related.

[tobiasschulz]

We are encountering this issue with several customers now. (Xamarin.Android 9.4, Mono 2019-02)

Is there any workaround? How can something like this break?

[Golemanova]

We are now using this instead of File.Copy:

            var fileBytes = File.ReadAllBytes(sourcePath);
            File.WriteAllBytes(destinationPath, fileBytes);

and this instead of File.Move:

            var fileBytes = File.ReadAllBytes(sourcePath);
            File.WriteAllBytes(destinationPath, fileBytes);
            File.Delete(sourcePath);

[grendello]

@grendello I cannot provide you with the exact project that is causing the issues.
Everything was working fine until we upgraded to Xamarin 9.4 which we did because we needed to create an app bundle.

The bug is easily reproduced, it happens every time File.Copy or File.Move is used. With the File.Copy I also get System.IO.IOException: Sharing violation on path /data/user/0/com.my.project/files/logs/20190801.log although I have asked the user the required permissions.

The project is active for two years now and we didn't have any of these issues before the update.

I tried to reproduce it on 6 different devices (no Samsung amongst them) and in the emulator - to no avail. I'm not asking for you to share your project, just a repro (if possible to create). If not possible - I need information on what devices (except for the Samsung mentioned somewhere above) it happens.

[steveisok]

@grendello I can reproduce the File.Copy issue on desktop Mono, so it's likely not specific to Android.

https://github.com/mono/mono/issues/16032

[brendanzagaeski]

Internal cross-referencing link for the Microsoft team:

VS bug #965685

[tobiasschulz]

Will the updated mono be in vs 16.2.3 ?

[kyle-seongwoo-jun]

Is there any progress here?

[brendanzagaeski]

A new Preview version has now been published that includes a fix for this item. The fix is not yet included in a Release version. I will update this issue again when a Release version is available that includes the fix.

Fix included in Xamarin.Android 10.0.0.40.

Fix included on Windows in Visual Studio 2019 version 16.3 Preview 3. To try the Preview version that includes the fix, check for the latest updates in Visual Studio Preview.

Fix included on macOS in Visual Studio 2019 for Mac version 8.3 Preview 3. To try the Preview version that includes the fix, check for the latest updates on the Preview updater channel.

[kyle-seongwoo-jun]

09-06 17:03:57.156 E/mono-rt (27466): [ERROR] FATAL UNHANDLED EXCEPTION: System.UnauthorizedAccessException: Access to the path is denied. ---> System.IO.IOException: Operation not permitted
09-06 17:03:57.156 E/mono-rt (27466):    --- End of inner exception stack trace ---
09-06 17:03:57.156 E/mono-rt (27466):   at Interop.ThrowExceptionForIoErrno (Interop+ErrorInfo errorInfo, System.String path, System.Boolean isDirectory, System.Func`2[T,TResult] errorRewriter) [0x00014] in <492bf9a8d40a4127a2682b6964cbb669>:0 
09-06 17:03:57.156 E/mono-rt (27466):   at Interop.CheckIo (System.Int64 result, System.String path, System.Boolean isDirectory, System.Func`2[T,TResult] errorRewriter) [0x0000a] in <492bf9a8d40a4127a2682b6964cbb669>:0 
09-06 17:03:57.156 E/mono-rt (27466):   at Interop.CheckIo (System.Int32 result, System.String path, System.Boolean isDirectory, System.Func`2[T,TResult] errorRewriter) [0x00000] in <492bf9a8d40a4127a2682b6964cbb669>:0 
09-06 17:03:57.156 E/mono-rt (27466):   at System.IO.FileSystem.CopyFile (System.String sourceFullPath, System.String destFullPath, System.Boolean overwrite) [0x0005c] in <492bf9a8d40a4127a2682b6964cbb669>:0 
09-06 17:03:57.156 E/mono-rt (27466):   at System.IO.FileSystem.LinkOrCopyFile (System.String sourceFullPath, System.String destFullPath) [0x0006f] in <492bf9a8d40a4127a2682b6964cbb669>:0 
09-06 17:03:57.156 E/mono-rt (27466):   at System.IO.FileSystem.MoveFile (System.String sourceFullPath, System.String destFullPath) [0x0003a] in <492bf9a8d40a4127a2682b6964cbb669>:0 
09-06 17:03:57.156 E/mono-rt (27466):   at System.IO.File.Move (System.String sourceFileName, System.String destFileName) [0x00083] in <492bf9a8d40a4127a2682b6964cbb669>:0 

@brendanzagaeski I'm sorry but it still crashes on VS 16.3 Preview 3.

What should I do for it?

[steveisok]

I had thought https://github.com/mono/mono/issues/16032 fixed the issue... However, in your case there may be something else.

Is your code the same as the sample in the issue description?

[LaDucha]

Several of my users are having this issue on their device. Is there a possible (temporary) workaround possible without having to use the preview version?

[kyurkchyan]

@LaDucha we use this instead of File.Copy.

using(FileStream sourceStream = File.Open(sourceFilePath, FileMode.Open, FileAccess.Read, FileShare.ReadWrite))
using(FileStream destinationStream = File.Create(destinationFilePath))
{
       await sourceStream.CopyToAsync(destinationStream);
}

Bear in mind, according to my benchmarks it's several times slower. So, it might not be right fit for your use case. In our case, it was acceptable as the files that the program was operating with, were pretty small, and the performance hit wasn't noticeable by the user (matter of several hundred milliseconds)

[brendanzagaeski]

Verification status: not yet resolved

Steps followed to test

1. Launch the attached test case in the Debug configuration.
2. Allow access to the storage when prompted in the app.
3. Tap the letter icon in the lower right corner of the screen.

Test case: FileCopyUnauthorized.zip

Actual results

When the app is built with Xamarin.Android 10.0.0.43 in Visual Studio 2019 version 16.3 or Xamarin.Android 10.0.99.100 in Visual Studio 2019 version 16.4 Preview, an unhandled exception is thrown:

System.UnauthorizedAccessException: Access to the path is denied. ---> System.IO.IOException: Operation not permitted
   --- End of inner exception stack trace ---
  at Interop.ThrowExceptionForIoErrno (Interop+ErrorInfo errorInfo, System.String path, System.Boolean isDirectory, System.Func`2[T,TResult] errorRewriter) [0x00014] in <46c2fa109b574c7ea6739f9fe2350976>:0 
  at Interop.CheckIo (System.Int64 result, System.String path, System.Boolean isDirectory, System.Func`2[T,TResult] errorRewriter) [0x0000a] in <46c2fa109b574c7ea6739f9fe2350976>:0 
  at Interop.CheckIo (System.Int32 result, System.String path, System.Boolean isDirectory, System.Func`2[T,TResult] errorRewriter) [0x00000] in <46c2fa109b574c7ea6739f9fe2350976>:0 
  at System.IO.FileSystem.CopyFile (System.String sourceFullPath, System.String destFullPath, System.Boolean overwrite) [0x0005c] in <46c2fa109b574c7ea6739f9fe2350976>:0 
  at System.IO.File.Copy (System.String sourceFileName, System.String destFileName, System.Boolean overwrite) [0x00062] in <46c2fa109b574c7ea6739f9fe2350976>:0 
  at System.IO.File.Copy (System.String sourceFileName, System.String destFileName) [0x00000] in <46c2fa109b574c7ea6739f9fe2350976>:0 
  at AndroidApp1.MainActivity.FabOnClick (System.Object sender, System.EventArgs eventArgs) [0x00088] in C:\Temp\AndroidApp1\AndroidApp1\MainActivity.cs:67 
  at Android.Views.View+IOnClickListenerImplementor.OnClick (Android.Views.View v) [0x00011] in <266395aeef1642bab2007ca31686faf9>:0 
  at Android.Views.View+IOnClickListenerInvoker.n_OnClick_Landroid_view_View_ (System.IntPtr jnienv, System.IntPtr native__this, System.IntPtr native_v) [0x00011] in <266395aeef1642bab2007ca31686faf9>:0 
  at (wrapper dynamic-method) Android.Runtime.DynamicMethodNameCounter.16(intptr,intptr,intptr)

Expected results

When the app is built with Xamarin.Android 9.3.0.23 in Visual Studio 2019 version 16.1.6, no exception is thrown.

The issue depends on the libmonosgen-2.0.so and mscorlib.dll version

Steps tested:

1. Build and deploy using Xamarin.Android SDK 9.4.1.1 (d16-2/cec9eb4)
2. Reconfirm the error.
3. Push libmonosgen-2.0.so and mscorlib.dll from Xamarin.Android SDK 9.3.0.23 (d16-1/ebd7bda) to the test app's files/.__override__ directory.

Result:

The File.Copy() call completes successfully.

The issue also depends on the device

Devices where the UnauthorizedAccessException occurs

Android 6.0 Marshmallow (API level 23) x86, Google APIs emulator (system-images;android-23;google_apis;x86)
Android 7.1 Nougat (API level 25) x86, Google APIs emulator (system-images;android-25;google_apis;x86)
Android 7.1 Nougat (API level 25) x86_64, Google APIs emulator (system-images;android-25;google_apis;x86_64)

Devices where the exception does not occur

Android 7.1 Nougat (API level 25) armeabi-v7a, Motorola Moto E4
Android 9.0 Pie (API level 28) x86, Google APIs emulator (system-images;android-28;google_apis;x86)
Android 9.0 Pie (API level 28) arm64-v8a, Google Pixel 3

[kyle-seongwoo-jun]

I tested the test case that @brendanzagaeski attached, and here's the result.

tested on VS 2019 Preview 16.3.0 Preview 4.0
(Xamarin.Android 10.0.0.43 (d16-3/8af1ca8), Mono: mono/mono/2019-06@7af64d1ebe9)

Devices where the UnauthorizedAccessException occurs

Android 7.0 Nougat (API level 24) arm64-v8a, LG V20

Devices where the exception does not occur

Android 8.0 Oreo (API level 26) arm64-v8a, Samsung Galaxy S7
Android 10 Q (API level 29) arm64-v8a, Google Pixel 3a

[derekcroprecords]

How is this not fixed yet? File.Copy and File.Move broken for 2 months????

[derekcroprecords]

We are seeing this problem on a Samsung Galaxy S6 (SM-G920W8) with Android 7.0
tested on VS 2019 16.3.1 Xamarin.Android SDK 10.0.0.43

[LaDucha]

@LaDucha we use this instead of File.Copy.

using(FileStream sourceStream = File.Open(sourceFilePath, FileMode.Open, FileAccess.Read, FileShare.ReadWrite))
using(FileStream destinationStream = File.Create(destinationFilePath))
{
       await sourceStream.CopyToAsync(destinationStream);
}

Bear in mind, according to my benchmarks it's several times slower. So, it might not be right fit for your use case. In our case, it was acceptable as the files that the program was operating with, were pretty small, and the performance hit wasn't noticeable by the user (matter of several hundred milliseconds)

Thanks!

I hope this is resolved soon however. I understand bugs can occur but this is really ridiculous and gives me unnecessary troubles. I have about 500 users in our company relying on my app. I can imagine apps with much more users...

[tobiasschulz]

Seriously, how is this not fixed yet?

[synteco-lab]

@tobiasschulz Looks like i've got the same right now...

[derekcroprecords]

More Devices where the UnauthorizedAccessException occurs

• Samsung S7 Edge Phone - Recently updated to Android 9 and still has the same problem
• Galaxy Tab S3 Tablet - Recently updated to Android 9 and still has the same problem.
  
  
  
  • Samsung Xcover 4 - Had the problem with Android 7, but upgraded to Android 9 and it fixed the problem
  
  

[brendanzagaeski]

Thanks for the additional testing!

Investigation update with some new information:

This issue appeared because File.Copy() and File.Move() now explicitly set the read, write, and execute permission mode bits for user, group, and other on the destination file to match the source file. The problem is that Android has special behavior for how file ownership and permissions work on external storage:

• At least on the devices I tested, files created on external storage are owned by root rather than the app itself.
• On some devices, attempting to change the permission mode bits on external storage files fails, so File.Copy() throws an exception.
• On other devices, attempting to change the permission mode bits on external storage files "pretends" to work. The fchmod() system call returns 0 (success), but the permission mode bits don't actually change. This allows File.Copy() to succeed.

I have submitted https://github.com/mono/mono/issues/17133 with additional details about the unusual way that permissions behave in the external storage directory on Android so that the Mono and CoreFX teams can consider whether File.Copy() should add special handling for it.

Suggested workaround for now

The workaround Golemanova suggested is one good way to avoid the problems caused by the special behavior of permissions on Android external storage.

Golemanova commented on Aug 14 https://github.com/xamarin/xamarin-android/issues/3426#issuecomment-520790110

We are now using this instead of File.Copy:

            var fileBytes = File.ReadAllBytes(sourcePath);
            File.WriteAllBytes(destinationPath, fileBytes);

and this instead of File.Move:

            var fileBytes = File.ReadAllBytes(sourcePath);
            File.WriteAllBytes(destinationPath, fileBytes);
            File.Delete(sourcePath);

[derekcroprecords]

Thanks for the additional action on this Issue.
I just want to point out that although replacing the File.Copy and File.Move with Golemanova's workaround above will work for code that we control, it doesn't fix the problem where File.Copy and File.Move are used within 3rd party dependencies and nuget packages included in the project.
So we may still get unexpected behaviour on android even though there is no code we can easily change.

[divil5000]

We are hitting this issue in production because we made the huge mistake of upgrading our Xamarin developer tools to their latest version. We should have known better.

The most unbelievable part of this is that this breaking change was ever allowed to ship. You shipped a change where a File.Copy operation would fail on external storage, and judging by our telemetry on a significant proportion of Android devices. It is unforgivable, and so is the delay in addressing your mistake. It used to be the case that Microsoft shipped higher quality code than this into their stable releases.

[vtserej]

@divil5000 you are completely right. it came up in 6.0 and it still broken in 6.4 .
it is happening in the following phones according to our telemetry
Galaxy J7(2016)
LG K20 Plus
Galaxy J7 Pop
Galaxy S7 edge

[hashmurali]

I am able to reproduce it using Zebra TC25 device running on Android version 7.1.2 but not in Zebra TC57 running on Android version 8.1

[lombardac]

Also HUAWEI EVA-L09 - Android 7: Golemanova's solution works a charm for now.

[hashmurali]

Thanks for the additional action on this Issue.
I just want to point out that although replacing the File.Copy and File.Move with Golemanova's workaround above will work for code that we control, it doesn't fix the problem where File.Copy and File.Move are used within 3rd party dependencies and nuget packages included in the project.
So we may still get unexpected behaviour on android even though there is no code we can easily change.

As pointed out above we cannot control 3rd party libraries in my case NLog, which broke since the Xamarin.Android update

[procopio]

Fixed my issue with Xamarin.Essentials.Share on last Visual Studio / Xamarin Android / Mono update.

[brendanzagaeski]

Release status update

A new Preview version has now been published that includes a fix for this item. The fix is not yet included in a Release version. I will update this item again when a Release version is available that includes the fix.

Fix included in Xamarin.Android 10.1.0.30.

Fix included on Windows in Visual Studio 2019 version 16.4 Preview 5. To try the Preview version that includes the fix, check for the latest updates in Visual Studio Preview.

Fix included on macOS in Visual Studio 2019 for Mac version 8.4 Preview 2.1. To try the Preview version that includes the fix, check for the latest updates on the Preview updater channel.

---

Verification status: Verified resolved in Xamarin.Android 10.1.0.30.

To verify the fix, I repeated the steps I ran in https://github.com/xamarin/xamarin-android/issues/3426#issuecomment-534423074.

I was able to reproduce the exception as before when using Visual Studio 2019 version 16.4 Preview 3 with Xamarin.Android 10.1.0.29.

I was no longer able to reproduce the exception when using Visual Studio 2019 version 16.4 Preview 5 with Xamarin.Android 10.1.0.30. I verified that the desired destination file was present in the external storage location after the call to File.Copy(). I similarly verified that the desired destination file was present when using File.Move() rather than File.Copy().

[brendanzagaeski]

Release status update

A new Release version has now been published on Windows that includes the fix for this item. The fix is not yet published in a Release version on macOS. I will update this item again when a Release version is available on macOS that includes the fix.

Fix included in Xamarin.Android 10.1.0.30.

Fix included on Windows in Visual Studio 2019 version 16.4. To get the new version that includes the fix, check for the latest updates or install the latest version from https://visualstudio.microsoft.com/downloads/.

(Fix also included on macOS in Visual Studio 2019 for Mac version 8.4 Preview 2.1 and higher. To try the Preview version that includes the fix, check for the latest updates on the Preview updater channel.)

[SubramanymRajuB]

If you are still getting UnauthorizedAccessException for write or read file in Xamarin Android. I just written article to resolve it
http://bsubramanyamraju.blogspot.com/2019/12/resolved-unauthorizedaccessexception.html

[divil5000]

SubramanymRajuB, you have completely missed the point. It is/was a bug in Mono, nothing to do with Android permissions.

[rkshnair]

_Release status update_

A new Release version has now been published on Windows that includes the fix for this item. The fix is not yet published in a Release version on macOS. I will update this item again when a Release version is available on macOS that includes the fix.

Fix included in Xamarin.Android 10.1.0.30.

Fix included on Windows in Visual Studio 2019 version 16.4. To get the new version that includes the fix, check for the latest updates or install the latest version from https://visualstudio.microsoft.com/downloads/.

(Fix also included on macOS in Visual Studio 2019 for Mac version 8.4 Preview 2.1 and higher. To try the Preview version that includes the fix, check for the latest updates on the Preview updater channel.)

When we can expect a stable release on this?

[acaliaro]

It's already stable: 16.4 (maybe 16.4.1 now)

[rkshnair]

It's already stable: 16.4 (maybe 16.4.1 now)

But for Mac it is 8.4 which is still in preview right? 8.3.11 is the stable release for mac it seems.

[brendanzagaeski]

Unfortunately I don't have information about when Visual Studio 2019 for Mac version 8.4 will move from Preview to Release. But I will be sure to update this item as soon as possible when it does.

[SharpMobileCode]

As severe as this bug is, I'm shocked that this isn't released as a hot fix.

[divil5000]

Microsoft appear to be asleep at the wheel. I totally agree they seriously underestimated how serious and debilitating this bug is. There's another one in the latest version of VS for PC, where all your conditional compilation settings and others are lost when looking at the project properties. No hotfix for that either, just a reference to trying some beta software which is out of the question for people creating stable releases.

[hwd71]

I had exactly this, on multiple droids, with File.Move() - x86_64/arm-v7, android 5,6,7 :
Access to the path is denied. INNER: Operation not permitted
For me, upgrade VS2019 to 16.4.2 appears to have fixed it :)

[SharpMobileCode]

@brendanzagaeski , any word on when we are going to get this fix for Mac?

[brendanzagaeski]

No news yet, but hopefully there will be some information soon as things get moving again in the new calendar year.

[divil5000]

If my product had a serious bug like this, I wouldn't have allowed myself to break for Christmas until I'd fixed it. Perhaps my work ethic is stronger than some at Microsoft.

[brendanzagaeski]

Just to make sure I didn't misrepresent any information, the code change that fixes this issue is integrated into a publicly available Xamarin.Android 10.1 package for macOS, but that package is compatibility-aligned with Visual Studio 2019 for Mac version 8.4, which has not yet moved from Preview to Release.

So when I say "as things get moving again in the new calendar year," I really just mean "when the next Visual Studio for Mac release gets scheduled, which will now necessarily be in 2020 because it didn't happen in 2019."

There wasn't specifically any unfinished work left to do on the Xamarin.Android 10.1 package for macOS in December. The situation is instead that the overall Visual Studio 2019 for Mac version 8.4 release, covering Xamarin and non-Xamarin workloads, did not end up moving from Preview to Release in December, so that move will now necessarily happen in 2020. Since Visual Studio for Mac version 8.4 is a feature release that covers a large number of products, I believe this particular File.Copy() issue for Xamarin.Android would only play a small part in determining the release schedule.

That said, this does not address the comment about a "hot fix" against the earlier Xamarin.Android 10.0 version in Visual Studio 2019 for Mac version 8.3 and Visual Studio 2019 version 16.3. I myself don't know much on that topic other than that I believe it would have only been considered before Visual Studio 2019 version 16.4 moved from Preview to Release on Windows. The team might need to reconsider that general approach in the future if there are similar delays between Release publication dates on macOS and Windows for future Visual Studio versions.

[derekcroprecords]

@brendanzagaeski
We don't care about the process or what release its scheduled in. Just get it done, it's been 5.5 months.
Its very obvious that the process isn't working.
This should have been fixed last August.
A bug in File.Copy deserves a release of it's own.
Do you not understand what a serious bug this is?

[brendanzagaeski]

Yes, I agree that the overall timeline for this issue was a problem and that the team needs to examine the reasons it took that time to avoid similar situations in the future. For now, I just wanted to make sure I wasn't providing inaccurate information.

[brendanzagaeski]

Release status update

A new Release version has now been published on macOS that includes the fix for this item.

Fix included in Xamarin.Android 10.1.1.0.

Fix included on macOS in Visual Studio 2019 for Mac version 8.4. To get the new version that includes the fix, check for the latest updates on the Stable updater channel.

(Fix also included on Windows in Visual Studio 2019 version 16.4 and higher. To get the new version that includes the fix, check for the latest updates or install the latest version from https://visualstudio.microsoft.com/downloads/.)

[ravinderjangra]

I'm not 100% sure if this one is completely solved or maybe I'm seeing a different issue. I am usingFiles.ReadAllText API and it's working fine up to API 28 but as soon as I run the code on Android 10 emulator, it starts showing this issue. The app already has the permissions setup in the manifest file and runtime permissions request/check as well.
Error:

System.UnauthorizedAccessException: Access to the path "/storage/emulated/0/Download/{some_file}" is denied.

StackTrace:

  at System.IO.FileStream..ctor (System.String path, System.IO.FileMode mode, System.IO.FileAccess access, System.IO.FileShare share, System.Int32 bufferSize, System.Boolean anonymous, System.IO.FileOptions options) [0x001aa] in /Users/builder/jenkins/workspace/archive-mono/2019-08/android/release/mcs/class/corlib/System.IO/FileStream.cs:239 
  at System.IO.FileStream..ctor (System.String path, System.IO.FileMode mode, System.IO.FileAccess access, System.IO.FileShare share, System.Int32 bufferSize, System.IO.FileOptions options) [0x00000] in /Users/builder/jenkins/workspace/archive-mono/2019-08/android/release/mcs/class/corlib/System.IO/FileStream.cs:106 
  at (wrapper remoting-invoke-with-check) System.IO.FileStream..ctor(string,System.IO.FileMode,System.IO.FileAccess,System.IO.FileShare,int,System.IO.FileOptions)
  at System.IO.StreamReader..ctor (System.String path, System.Text.Encoding encoding, System.Boolean detectEncodingFromByteOrderMarks, System.Int32 bufferSize) [0x00055] in /Users/builder/jenkins/workspace/archive-mono/2019-08/android/release/external/corefx/src/Common/src/CoreLib/System/IO/StreamReader.cs:182 
  at System.IO.StreamReader..ctor (System.String path, System.Text.Encoding encoding, System.Boolean detectEncodingFromByteOrderMarks) [0x00000] in /Users/builder/jenkins/workspace/archive-mono/2019-08/android/release/external/corefx/src/Common/src/CoreLib/System/IO/StreamReader.cs:167 
  at (wrapper remoting-invoke-with-check) System.IO.StreamReader..ctor(string,System.Text.Encoding,bool)
  at System.IO.File.InternalReadAllText (System.String path, System.Text.Encoding encoding) [0x00000] in /Users/builder/jenkins/workspace/archive-mono/2019-08/android/release/external/corefx/src/System.IO.FileSystem/src/System/IO/File.cs:303 
  at System.IO.File.ReadAllText (System.String path) [0x00026] in /Users/builder/jenkins/workspace/archive-mono/2019-08/android/release/external/corefx/src/System.IO.FileSystem/src/System/IO/File.cs:282 
  at SafeAuthenticator.ViewModels.VaultConnectionFileViewModel.PickFileFromTheDeviceAsync () [0x0016d] in /Users/maidsafe/Desktop/GitHub/safe-authenticator-mobile/SafeAuthenticator/ViewModels/VaultConnectionFileViewModel.cs:225 

Not much or any information in the logs.

[brendanzagaeski]

@ravinderjangra, yes, that sounds like a different behavior. Specifically, it sounds like the new scoped storage behavior of Android 10:

https://developer.android.com/training/data-storage/#scoped-storage

It sounds like the Download directory would be outside of the app-specific external storage directory, so it wouldn't be included in the app's external storage scope.

One way to confirm that scoped storage is involved would be to disable it temporarily: https://developer.android.com/training/data-storage/compatibility. (Note that you'll need to set Compile using Android version to Android 10.0 under the Application tab of the project property pages to use the android:requestLegacyExternalStorage attribute.)

If that doesn't stop the exception, then if you could submit a new issue with a snippet of the code you're using so the team can take a look, that would be perfect. Thanks!

[RSF-Deus]

I can confirm that the issue persists, but only with some devices, and only the first time the user launches the app, and only with release builds (this last one might be specific to our environment though) !

This workaround found earlier in this thread :

var fileBytes = File.ReadAllBytes(sourcePath);
File.WriteAllBytes(destinationPath, fileBytes);
File.Delete(sourcePath);

Worked apparently very well.