@baulig Other platforms (for example mounted exfat/ntfs/cloud filesystems) don’t allow modifying permissions either. So it would likely fail there too and not just android. In mono 6.0 it would fail after the write, now the problem simply got moved to the top of CopyFile and you end up with a 0 length file.
The exact same problem still persists for #16573 (it was discussed here, but not addressed)
The fundamental issue is the assumption that chmod should succeed here. In mono < 6.0, File.Copy didn’t even copy permissions. Now it does, and fails if it can’t.
This is essentially an upstream corefx issue ever since dotnet core 1.0, but it effectively broke CopyFile (and MoveFile cross-filesystems) for mono 6+.
Please realize the gravity of this. Anyone using certain filesystem mounts like, cloud, fat, ntfs, etc. (The likely only reason why you might not have heard about these issues more frequently is that the end user doesn’t know the underlying problem and just downgrades to mono 5.x)
The workaround (using the managed CopyTo) is pure insanity. Every app would have to write it’s own replacement for File.Copy and File.Move, they won’t be able to use the faster kernel-level operations that SystemNative_CopyFile implements.
Maybe worth noting that on Windows, copying a file in Windows Explorer doesn’t copy the file ACLs, neither does a net462 & netcore app.
File.Copy should not preserve permissions. File.Move should preserve permissions (even if it has to fall back to a Copy on cross-filesystem), but should not fail doing so if it can’t.
Any advanced situation where the user wants the permissions to be copied requires a new api.