Mirror backup will not delete files on destination - on one drive

Get help for specific problems
Posts: 37
Joined: 13 Aug 2019

Louiscar

Hi,

I've seen some similar things here but I cannot find the exact problem nor the solution.

I recently moved to another computer and my back up drives on the external enclosure was connected.

I had 2 drives in the backup being written to but one was being used by the previous computer and will come up with an error on the new one.

I set up a test folder which can be seen in the attached graphic.
"H:\Wacom Driver\Read Me.rtf" to
"H:\Wacom Driver\RecycleBin~59c0.ffs_tmp\Read Me.rtf".

ERROR_ACCESS_DENIED: Access is denied. [MoveFileEx]
The "RecycleBin~59c0.ffs_tmp" is only created when the backup has started and disappears when. I cancelled. I have tried deleting it and retrying and it just re-creates it. I have tried changing ownership of the folder and permissions and nothing seems to help. This drive is will not allow a mirror backup where something on that drive needs to be deleted.

The test is an unrelated folder which I decided to see if it's a problem just in the back up folder. This proves that this will happen on that drive regardless - the "Wacom" folder was NEVER part of any FFS backup routine on my other computer

The actual name of the RecycleBin~59c0.ffs_tmp will change to have different numbers after the tilde sign.

Any ideas how I can get out of this mess without formatting the drive completely and starting again?
Attachments
Untitled.jpg
Untitled.jpg (163.26 KiB) Viewed 258 times
Posts: 37
Joined: 13 Aug 2019

Louiscar

Grrrrr - OK as I posted I suddenly thought about running FFS as administrator and it works.
Posts: 4908
Joined: 11 Jun 2019

xCSxXenon

Confirms that it is likely a permission issue. The files that are involved with the errors were created under a different Windows user and now you were trying to delete them with a different user. You could change the permissions of the root of the drive and apply changes to subfolders, but running as admin and reformatting is my recommendation.
Posts: 37
Joined: 13 Aug 2019

Louiscar

Thanks for confirming.
I tried to sort the permissions out but failed. I transferred ownership however, since the folder disappears when the dialog is closed and changes name it's not surprising. I could not remove - "owner creator" I could only take ownership of the drive to "administrators" and enable permissions none of which worked.

Annoyingly this situation affects the whole drive completely and the backup folder is only a small part of the files on the drive. Very frustrating and makes it somewhat pointless to use an external drive enclosure to move from one machine to another.

Running as admin as you say is the only way and reformatting is out of the question not just because I use the drive on different pcs but because the drive has a mass of other stuff on it which would be a nightmare to relocate only for the same situation to occur again.

The best solution is for a way to get rid of this via FFS particularly as the folder in question is a ghost which dodges any solution to get rid of it. If it's created at the point of backup then it's possible to stop this being created surely?
Posts: 4908
Joined: 11 Jun 2019

xCSxXenon

FFS simply respects Windows/NTFS permissions, it doesn't really have a choice to ignore them besides running as administrator. As for my suggestion to reformat, you would copy the data off first instead of relocating the data. You could run a mirror sync using FFS as admin even, then format, then sync back without running FFS as admin
Posts: 1222
Joined: 8 May 2006

therube

> the "Wacom" folder was NEVER part of any FFS backup routine on my other computer

Did you have a Wacom tablet (or whatever) on the old computer?

What were your folder pairs for "test"?
Posts: 37
Joined: 13 Aug 2019

Louiscar

> the "Wacom" folder was NEVER part of any FFS backup routine on my other computer

Did you have a Wacom tablet (or whatever) on the old computer?
therube, 10 Nov 2025, 17:23
The Wacom folder is irrelevant, the test was just to prove that a completely unrelated back up folder which has never been part of a back up routing will yield the same result.

In other words the whole drive is screwed by this problem regardless when only 1 folder was ever part of a backup routine