How the Readonly Attribute Works
The readonly flag is a simple boolean indicator within the file's attributes field in the NTFS MFT entry. When you set this attribute via Explorer or the command line, the operating system updates the file record to reflect that the file should be treated as read-only. This change happens instantly because it involves writing to the directory structure and the MFT, not the file's data stream.
It is important to understand that this attribute is distinct from NTFS Access Control Lists (ACLs). While ACLs define who can open a file and with what rights (Read, Write, Execute), the readonly attribute is a legacy compatibility feature that tells applications to refuse write operations if they respect standard POSIX or Windows conventions. However, it is not a security boundary. A user with appropriate permissions can still delete the file even if it is marked readonly, provided they have Delete permission on the parent folder. This common misconception often leads to confusion about whether the file itself has been altered.
Metadata vs. Data Streams
When you toggle the readonly state, only specific metadata fields are updated. These include the file attributes byte, which stores the readonly flag, and potentially the Last Modified timestamp, depending on the tool used. Crucially, the file size, creation time, and most importantly, the actual data bytes remain unchanged. No new sectors are allocated, and no existing sectors are overwritten.
This behavior contrasts sharply with operations that genuinely rewrite files. For instance, when you edit a document in a word processor and save it, the application may create a temporary file, write the new content to it, and then rename it over the original. In that scenario, the old data is eventually deallocated, and new data is written. Changing the readonly attribute bypasses all of this. It is purely a label change. If you were to compare the file hash before and after toggling the readonly bit, the result would be identical.
Impact on Timestamps
There is often debate regarding whether changing attributes affects timestamps. On modern NTFS versions, setting the readonly attribute typically updates the "Last Modified" timestamp. This is because the file record itself is being modified. However, the "Created" and "Last Accessed" timestamps usually remain stable unless the file is actively accessed during the operation. It does not trigger a full rewrite of the file contents, so the physical location of the data on the drive does not shift. This is why forensic tools can often recover "deleted" readonly files easily; the data was never touched.
Permissions and Deletion Nuances
A frequent point of confusion is the relationship between the readonly attribute and deletion. Many users believe that a readonly file cannot be deleted. This is false. Deletion is controlled by the Delete permission on the containing directory, not the readonly flag on the file. You can delete a readonly file without issue if your user account has the necessary rights. The readonly flag merely prevents modifications to the file's content while it exists. It acts as a soft lock against accidental edits, not a hard barrier against removal.
If you need true protection against modification, you must rely on NTFS ACLs. By removing Write access for specific users or groups, you enforce a security policy that the operating system kernel respects regardless of the readonly attribute. The readonly attribute is largely ignored by high-privilege processes or scripts that use low-level API calls to force writes. Therefore, relying solely on the readonly checkbox for security is ineffective.
Practical Implications for System Administrators
For administrators managing large sets of files, understanding this distinction is vital for scripting and automation. Tools like PowerShell's Set-ItemProperty or the attrib command modify the MFT entry directly. They do not invoke file I/O operations that would rewrite the data. This makes them extremely fast, even for large files. There is no performance penalty for toggling readonly on a 10GB video file compared to a 1KB text file.
However, be cautious when using third-party backup or synchronization tools. Some older utilities might misinterpret the readonly flag and skip files entirely, assuming they are immutable. Modern tools generally handle this correctly by checking both the attribute and the ACLs. If you encounter issues where files are not syncing, check if the readonly attribute is set and remove it temporarily, rather than worrying about data corruption.
Comparison with Other File Systems
While this behavior is standard for NTFS, other filesystems may handle attributes differently. For example, FAT32 also uses a readonly bit but lacks the sophisticated ACL support of NTFS. In networked environments, protocols like SMB or NFS may map these local attributes to remote permissions differently. Always verify how your specific environment interprets the readonly flag, especially when dealing with cross-platform data exchange.
Frequently Asked Questions
Can I delete a readonly file in Windows?
Yes, you can delete a readonly file if your user account has Delete permission on the parent folder. The readonly attribute only prevents content modification, not deletion. You may receive a confirmation dialog, but the operation will succeed.
Does changing readonly update the file hash?
No, changing the readonly attribute does not alter the file content, so the cryptographic hash remains exactly the same. Only the metadata in the MFT changes, which is separate from the data stream.
Why do some programs refuse to overwrite a readonly file?
Programs check the readonly attribute to prevent accidental data loss. If the flag is set, the application typically blocks write operations or prompts the user for confirmation. This is an application-level check, not a filesystem enforcement.
Is readonly a secure way to protect files?
No, readonly is not secure. Users with administrative privileges or those using low-level APIs can ignore the flag. To truly protect files, you should use NTFS Access Control Lists to restrict write permissions.
Does changing readonly affect the file size?
No, the file size remains unchanged. The operation only modifies a few bytes in the file record header within the Master File Table, leaving the data clusters intact.