I recently did a clean installation of Windows 10 onto a new SSD, and restored my old data files onto the drive. The problem is, even though I told the backup program to NOT restore the permissions, they ended up getting messed up anyway.
I've already executed takeown /f c:\src /r /d Y
I tried going into Explorer's properties -> security, added my user with permission "FULL CONTROL" to the folder, and applied it to the childern. Windows ran for a half hour supposedly doing it, yet Attributes: "Read Only" was STILL filled in with a square.
I cleared the "Read Only" square, applied it recursively, Windows ran for another 15-20 minutes... and the fscking square is STILL filled in.
I think I need to use ICACLS... but I'm afraid to, without guidance. Literally every single time I've EVER used ICACLS in the past to try and fix a situation like this, it's ended up making the problem worse. I understand Unix-style permissions and ownership just fine, but NTFS permissions have beaten me up every single time I've ever made the mistake of tangling with them.
In the past, I've used my traditional work-around to fix this through brute force: boot into Linux, recursively copy the directory (saving timestamps) to a FAT32 volume, boot back into Windows, delete the original directory from the NTFS volume, then copy it back from the FAT32 volume with the NTFS permissions cleansed away. I can't do that now... the directory contains too many 4-gig+ files.
So... how can I achieve something comparable (presumably, using ICACLS)?
Solution:
Based upon the answer below, here's what worked.
icacls c:\src /reset /T /L /Q
takeown /f c:\src /r /d Y (I re-ran takeown after icacls, just in case)
attrib -r -h -s c:\src /s /d
It turns out, as per This answer, this is just a case of Windows Explorer having extraordinarily poor UI design. Simply put, Windows will NEVER report that the contents of a folder are "not readonly". You can use the checkbox to try and clear or set the readonly status of files contained within the folder, but the state of the checkbox does not itself indicate anything meaningful about their present state.
Apparently, Microsoft's rationale is that every Explorer folder contains a hidden system file that, from the perspective of a user, is read-only (and if the file isn't there, Explorer pretends that there is). Therefore, every folder contains at least one file that's read-only, even if no files deliberately put there by the user are read-only. Sigh.
Anyway, my problem is now fixed. Gradle and Android Studio are able to build the files without dying due to a permissions error, so resetting the ACLs, taking ownership, and clearing the readonly and system flags (if they were there at all) solved the problem.
