Improve permission error reporting in flutter create #63528
Description
We're currently seeing a large increase in permission errors (access denied) during flutter create on Windows.
Example:
FileSystemException: Cannot copy file to 'C:\<elided>\app\android\app\src\main\res\mipmap-hdpi\ic_launcher.png', path = 'C:\<elided>\flutter\packages\flutter_tools\templates\app\android.tmpl\app\src\main\res\mipmap-hdpi\ic_launcher.png' (OS Error: Acceso denied.
, errno = 5)
| at _File.throwIfError | (file_impl.dart:635)
-- | -- | --
| at _File.copySync | (file_impl.dart:340)
| at ForwardingFile.copySync | (forwarding_file.dart:30)
| at ForwardingFile.copySync | (forwarding_file.dart:30)
| at Template.render.<anonymous closure> | (template.dart:256)
| at _LinkedHashMapMixin.forEach | (compact_hash.dart:377)
| at Template.render | (template.dart:182)
| at CreateCommand._renderTemplate | (create.dart:781)
| at _rootRunUnary | (zone.dart:1198)
| at _CustomZone.runUnary | (zone.dart:1100)
| at _FutureListener.handleValue | (future_impl.dart:143)
| at Future._propagateToListeners.handleValueCallback | (future_impl.dart:696)
| at Future._propagateToListeners | (future_impl.dart:725)
| at Future._completeWithValue | (future_impl.dart:529)
| at _AsyncAwaitCompleter.complete | (async_patch.dart:40)
| at _completeOnAsyncReturn | (async_patch.dart:311)
| at Template.fromName | (template.dart)
| at _rootRunUnary | (zone.dart:1198)
| at _CustomZone.runUnary | (zone.dart:1100)
| at _FutureListener.handleValue | (future_impl.dart:143)
| at Future._propagateToListeners.handleValueCallback | (future_impl.dart:696)
| at Future._propagateToListeners | (future_impl.dart:725)
| at Future._completeWithValue | (future_impl.dart:529)
| at _AsyncAwaitCompleter.complete | (async_patch.dart:40)
| at _completeOnAsyncReturn | (async_patch.dart:311)
| at _templateImageDirectory | (template.dart)
| at _rootRunUnary | (zone.dart:1198)
| at _CustomZone.runUnary | (zone.dart:1100)
| at _FutureListener.handleValue | (future_impl.dart:143)
| at Future._propagateToListeners.handleValueCallback | (future_impl.dart:696)
| at Future._propagateToListeners | (future_impl.dart:725)
| at Future._completeWithValue | (future_impl.dart:529)
| at _AsyncAwaitCompleter.complete | (async_patch.dart:40)
| at _completeOnAsyncReturn | (async_patch.dart:311)
| at loadPackageConfigWithLogging | (package_map.dart)
| at _rootRunUnary | (zone.dart:1198)
| at _CustomZone.runUnary | (zone.dart:1100)
| at _FutureListener.handleValue | (future_impl.dart:143)
| at Future._propagateToListeners.handleValueCallback | (future_impl.dart:696)
| at Future._propagateToListeners | (future_impl.dart:725)
| at Future._completeWithValue | (future_impl.dart:529)
| at _AsyncAwaitCompleter.complete | (async_patch.dart:40)
| at _completeOnAsyncReturn | (async_patch.dart:311)
| at readAnyConfigFileUri | (package_config_io.dart)
| at _rootRunUnary | (zone.dart:1198)
| at _CustomZone.runUnary | (zone.dart:1100)
| at _FutureListener.handleValue | (future_impl.dart:143)
| at Future._propagateToListeners.handleValueCallback | (future_impl.dart:696)
| at Future._propagateToListeners | (future_impl.dart:725)
| at Future._completeWithValue | (future_impl.dart:529)
| at Future._asyncCompleteWithValue.<anonymous closure> | (future_impl.dart:567)
| at _rootRun | (zone.dart:1190)
| at _CustomZone.run | (zone.dart:1093)
| at _CustomZone.runGuarded | (zone.dart:997)
| at _CustomZone.bindCallbackGuarded.<anonymous closure> | (zone.dart:1037)
| at _microtaskLoop | (schedule_microtask.dart:41)
| at _startMicrotaskLoop | (schedule_microtask.dart:50)
| at _runPendingImmediateCallback | (isolate_patch.dart:118)
| at _RawReceivePortImpl._handleMessage | (isolate_patch.dart:169)
While this error has cropped up before, the large increase is troubling. We're also not sure whether this is a problem in reading the file, or writing to the destination.
The Dart VM recently changed how file copy is implemented on windows, but this logic will fall back to the previous behavior if that fails.
To figure out what is going on here, we could try to test the source directory to verify that it has the correct permissions - exiting with a better error if they are lacking. This would help us narrow down the cause of this crash to an issue with the destination.