Windows 11 file archive bit set inappropriately

I had a similar issue with an old backup script (.bat) I'd used on a domain server for years. After I "upgraded" to Server 2016, I noticed that xcopy /m was no longer clearing the archive bit. I turned out that the account I was using to run the script in Task Scheduler was not running with Administrator privilege. This privilege was not previously required in order to clear the bit, but it is now. I had to add the account to the Administrators group, and then in Task Scheduler, I had to check the box "Run with the highest privileges" on the task setting. The archive bits are now being cleared with xcopy /m.

On Windows 11, when using attrib in a console window, you must first open the console with "Run as Administrator" before it will clear the bit.

I use XCOPY with the /m switch at the command prompt. This copies only files which have the archive bit set, and the operation also simultaneously clears the bit. After that, the bit is supposed to be re-set only if a file is modified. This is how the XCOPY command knows which files have changed since the last backup. But in Win 11, the archive bit is sometimes being set when the file is simply examined and NOT changed. This is not supposed to happen.

The experiment you described is how it's supposed to work.

The problem is not with XCOPY. Using the /m switch, XCOPY does exactly as it's supposed to -- copying only files with the archive attribute and then clearing those bits.

Here is another bit of info: the incorrect setting of the bit seems to happen only when I open a file from the command line (by typing the filename followed by <enter>). This is the way I do almost everything on my machine. I rarely use Explorer for anything.

I am astounded that this problem has not been reported before. It is a major issue.

In that case I think the best option is to report the bug using the Feedback Hub in Windows 11, winkey+f. That reports direct to the dev team.

You may not get a direct response but that is the only way to make Microsoft aware.

This is a user community forum and not manned by Microsoft personnel.

As I am using Windows 11 now, unlike during my previous post, I have just tested a text file and removed the archive bit using attrib -a command then opened the txt file using notepad. After that checked the attribute again in cmd and the archive bit is still missing.

If I edit the file in notepad and save it then the archive bit is back. So it seems xcopy is not doing what it should.

Do you get the same if you remove the attribute manually?

Running a very basic test of xcopy /m on a txt file it seems to work for me as you described you expected. So the attribute is removed when xcopy /m runs and if run again it states 0 files copied. If I edit the txt file and run it again it prompts to overwrite the destination file.

Do you see a problem with only certain file extensions or is it random.?

I had to do some checking because it is a long time since I've even thought about that attribute.

I'm looking at Windows 10 currently but I'm sure Windows 11 will be the same and has been since DOS.

Used this for ref File attribute - Wikipedia

All windows files have archive set and the archiving software updates successful after a backup. (is that what you want to happen)

What are you using to backup files?

I do see all user files in Windows 10 have the archive bit set. (even though File History has backed them up)