0

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.

1

"Attributes: [✔] Read Only" is not an NTFS permission flag to begin with. It is a completely separate set of per-file flags – often known as the "MS-DOS attributes". (Compare Linux chattr.)

This attribute, along with "Hidden" and "System" and "Archive", actually originates in the DOS FAT filesystem, so you won't get rid of them by copying files to a FAT32 volume and back.

To remove them recursively,

  1. You must have the "Write Attributes" permission for those files and folders.

  2. attrib -r -h -s c:\src /s /d


These attributes can be accessed on Linux as the system.ntfs_attrib_be xattr, for example:

setfattr -n system.ntfs_attrib_be -h -v 0x00000020 <filename>
  • Check out my update. The problem still hasn't gone away. – Bitbang3r Jul 23 at 18:41
  • Does attrib show the R flag on any of your files or directories? – grawity Jul 23 at 20:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.