Encountering "Element not found" on File History Cleanup

I can live without clean up not sure if file restore words not need to try.

They need bring back Ballmer, these Millennials fools are destroying Windows but hey they gave us 1000's of emoji's.

Having this exact issue on 21H1 build number 19043.1052

An In-place upgrade didn't fix the issue, nor did the File History reset .bat, so it might be caused by the folder on the backup drive. It might also be related to the fact that Windows has been reset multiple times since I've been using my backup folder.

For me the best solution is to make a new backup folder and rename the existing folder to .old and delete the old backups once a month or so has past to make sure I no longer need them.

I have over six months of backed up files in my current file history and planned on purging old data before moving to a new drive to make the move faster but I guess that's not an option due to Microsoft's bugs.

Also this isn't the first time I've had issues with File History:

File History new setup doesn't work

With the upcoming release of Windows 11 I'm concerned critical issues like this might not be fixed once development resources are moved away from Win 10.

Yeah even after a new install and/or repairing it I still get this error now. Sad to see MSFT degrade in such a manner. They've literally given up.

Ah I thought you might have found a winner here @Bree... but unfortunately, that doesn't work for me.

Haha doh... well, at least we know we're not alone with our grief. Please do continue to see if you can find a way to work around this. Currently, I have to re-configure/re-apply File History from scratch every time it reaches capacity, which is not a pleasant experience, to say the least.

I have found the solution to this issue.

When you look at your files in PowerShell doing a "dir" command on them, you'll see something like this.

Directory: D:\FileHistory\XXX\BT-XX\Data\C\Users\XXXX\Documents

dir Out*

Mode LastWriteTime Length Name
---- ------------- ------ ----
d----- 2022-09-30 12:11 OUTLOOK.BACKUP.20220910
d----- 2022-09-30 12:46 Outlook Rules
d----- 2022-09-30 12:46 Outlook Personal Folders
d----- 2022-09-30 13:25 Outlook Files
-ar--- 2016-03-13 13:08 19673 Outlook Rules 20160313 (2022_09_30 13_30_15 UTC).rwz
-ar--- 2012-09-13 13:39 28488 Outlook Rules 20120913 (2022_09_30 13_30_15 UTC).rwz
-ar--- 2022-09-30 15:27 33919878144 Outlook (2022_09_30 19_44_57 UTC).pst
-ar--- 2022-10-03 18:31 33940448256 Outlook (2022_10_03 22_32_14 UTC).pst
-ar--- 2022-10-04 02:41 33940448256 Outlook (2022_10_04 06_54_55 UTC).pst
-ar--- 2022-10-04 12:50 33940448256 Outlook (2022_10_04 16_50_50 UTC).pst

The -ar---- is the problem. The 'a' is for archive, and the 'r' is for READ-ONLY!!!!!!!!! WHY DO THEY DO THIS TO US?!?!?

If you try to delete one of these files from PowerShell with the rm command, it will not allow it and give you this message:

… Cannot remove item ……………… You do not have sufficient access rights to perform this operation.
At line:1 char:1
+ rm '.\Outlook (2022_10_03 22_32_14 UTC).pst ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : PermissionDenied: (D:\FileHistory\...35_35 UTC.ost :FileInfo) [Remove-Item], IOException
+ FullyQualifiedErrorId : RemoveFileSystemItemUnAuthorizedAccess,Microsoft.PowerShell.Commands.RemoveItemCommand

You can add the -force to your rm command and it WILL delete it immediately.

In Windows Explorer, look at the properties of the "FileHistory" folder. It will have [X] READ-ONLY checked. If you un-check it, it'll say:
You have chosen to make the following attribute changes:
unset read-only

Do you want to apply this change to this folder only, or do you want to apply it to all subfolders and files as well?

When I select the default "Apply changes to this folder, subfolders and files", it will go through the entire structure and turn off read-only on the files.

When you go back to that directory in PowerShell, they will now look like this:


Mode LastWriteTime Length Name
---- ------------- ------ ----
d----- 2022-09-30 12:11 OUTLOOK.BACKUP.20220910
d----- 2022-09-30 12:46 Outlook Rules
d----- 2022-09-30 12:46 Outlook Personal Folders
d----- 2022-09-30 13:25 Outlook Files
-a---- 2016-03-13 13:08 19673 Outlook Rules 20160313 (2022_09_30 13_30_15 UTC).rwz
-a---- 2012-09-13 13:39 28488 Outlook Rules 20120913 (2022_09_30 13_30_15 UTC).rwz
-a---- 2022-09-30 15:27 33919878144 Outlook (2022_09_30 19_44_57 UTC).pst
-a---- 2022-10-03 18:31 33940448256 Outlook (2022_10_03 22_32_14 UTC).pst
-a---- 2022-10-04 02:41 33940448256 Outlook (2022_10_04 06_54_55 UTC).pst
-a---- 2022-10-04 12:50 33940448256 Outlook (2022_10_04 16_50_50 UTC).pst

Now you can run the FileHistory "Clean up versions", select whatever parameter under "Delete files:" (Older than 1 year… etc…)

This should work. But why do we have to do this extra step?
Why doesn't Windows know that if we can create the file, we should be able to delete it.

Let me know if anyone finds anything else out.

ATB,
Josef

JosephUK said:

I have found the solution to this issue.

When you look at your files in PowerShell doing a "dir" command on them, you'll see something like this.

Directory: D:\FileHistory\XXX\BT-XX\Data\C\Users\XXXX\Documents

dir Out*

Mode LastWriteTime Length Name
---- ------------- ------ ----
d----- 2022-09-30 12:11 OUTLOOK.BACKUP.20220910
d----- 2022-09-30 12:46 Outlook Rules
d----- 2022-09-30 12:46 Outlook Personal Folders
d----- 2022-09-30 13:25 Outlook Files
-ar--- 2016-03-13 13:08 19673 Outlook Rules 20160313 (2022_09_30 13_30_15 UTC).rwz
-ar--- 2012-09-13 13:39 28488 Outlook Rules 20120913 (2022_09_30 13_30_15 UTC).rwz
-ar--- 2022-09-30 15:27 33919878144 Outlook (2022_09_30 19_44_57 UTC).pst
-ar--- 2022-10-03 18:31 33940448256 Outlook (2022_10_03 22_32_14 UTC).pst
-ar--- 2022-10-04 02:41 33940448256 Outlook (2022_10_04 06_54_55 UTC).pst
-ar--- 2022-10-04 12:50 33940448256 Outlook (2022_10_04 16_50_50 UTC).pst

The -ar---- is the problem. The 'a' is for archive, and the 'r' is for READ-ONLY!!!!!!!!! WHY DO THEY DO THIS TO US?!?!?

If you try to delete one of these files from PowerShell with the rm command, it will not allow it and give you this message:

… Cannot remove item ……………… You do not have sufficient access rights to perform this operation.
At line:1 char:1
+ rm '.\Outlook (2022_10_03 22_32_14 UTC).pst ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : PermissionDenied: (D:\FileHistory\...35_35 UTC.ost :FileInfo) [Remove-Item], IOException
+ FullyQualifiedErrorId : RemoveFileSystemItemUnAuthorizedAccess,Microsoft.PowerShell.Commands.RemoveItemCommand

You can add the -force to your rm command and it WILL delete it immediately.

In Windows Explorer, look at the properties of the "FileHistory" folder. It will have [X] READ-ONLY checked. If you un-check it, it'll say:
You have chosen to make the following attribute changes:
unset read-only

Do you want to apply this change to this folder only, or do you want to apply it to all subfolders and files as well?

When I select the default "Apply changes to this folder, subfolders and files", it will go through the entire structure and turn off read-only on the files.

When you go back to that directory in PowerShell, they will now look like this:


Mode LastWriteTime Length Name
---- ------------- ------ ----
d----- 2022-09-30 12:11 OUTLOOK.BACKUP.20220910
d----- 2022-09-30 12:46 Outlook Rules
d----- 2022-09-30 12:46 Outlook Personal Folders
d----- 2022-09-30 13:25 Outlook Files
-a---- 2016-03-13 13:08 19673 Outlook Rules 20160313 (2022_09_30 13_30_15 UTC).rwz
-a---- 2012-09-13 13:39 28488 Outlook Rules 20120913 (2022_09_30 13_30_15 UTC).rwz
-a---- 2022-09-30 15:27 33919878144 Outlook (2022_09_30 19_44_57 UTC).pst
-a---- 2022-10-03 18:31 33940448256 Outlook (2022_10_03 22_32_14 UTC).pst
-a---- 2022-10-04 02:41 33940448256 Outlook (2022_10_04 06_54_55 UTC).pst
-a---- 2022-10-04 12:50 33940448256 Outlook (2022_10_04 16_50_50 UTC).pst

Now you can run the FileHistory "Clean up versions", select whatever parameter under "Delete files:" (Older than 1 year… etc…)

This should work. But why do we have to do this extra step?
Why doesn't Windows know that if we can create the file, we should be able to delete it.

Let me know if anyone finds anything else out.

ATB,
Josef

Excellent find! I can confirm that my folder was also set to read only. Unfortunately this didn't fix the issue for me, but will continue to investigate and may remap my drive. (It's a NAS, will double check permissions)

Bummer I was hoping the Read-only issue would fix it for me but it did not, either.