freefilesync seemingly wanted to write a bunch of *.ffs_tmp files alongside normal files?
and actually it should back up from a FAT32 file-system to an NTFS file-system.
But it said it could not write thisAndThat *.ffs_tmp file(s).
That was when I left my PC in the morning, I took a look at the backup that ran overnight, and the section I took a short look at before going to work, showed that FFS wanted to write some *.ffs_tmp files when backing up *.tif files.
- Whut in the name of the holy nut is going on here?
- Why does it actually write *.ffs_tmp files?
- What are they good for?
- Can I avoid writing *.ffs_tmp files?
and one more more or less non-related question:
Is there any section in the forum where i can post error logs - and where sumbudy will tell me what kind of strange things else are going on -- on the basis of this log?
ffs_tmp files - cannot be written - whut?
- Posts: 1
- Joined: 20 Aug 2020
-
- Posts: 2283
- Joined: 22 Aug 2012
See e.g. here.
The tmp-versions mentioned there are the files with the *.ffs_tmp extension.
And yes, you can avoid writing *.ffs_tmp files by setting the FailSafeFileCopy flag to False in the GlobalSettings.xml file. But this obviously creates a risk when something goes wrong while copying data.
Note that the location of the GlobalSettings.xml file used depends on the user credentials under which FFS is run. See the second bullet in the Note in the section "A. Windows Task Scheduler:" here.
But first of all: make sure the user under which credentials FFS is run has write (and rename) access to the folders involved.
The tmp-versions mentioned there are the files with the *.ffs_tmp extension.
And yes, you can avoid writing *.ffs_tmp files by setting the FailSafeFileCopy flag to False in the GlobalSettings.xml file. But this obviously creates a risk when something goes wrong while copying data.
Note that the location of the GlobalSettings.xml file used depends on the user credentials under which FFS is run. See the second bullet in the Note in the section "A. Windows Task Scheduler:" here.
But first of all: make sure the user under which credentials FFS is run has write (and rename) access to the folders involved.
-
- Posts: 55
- Joined: 15 Feb 2018
I've seen various ffs_tmp errors at times in 2 different scenarios:
1) (as Plerry just said) The security ACLs or rights are not permissive enough in the destination folder or specific files. Windows security settings can get out of whack, and Microsoft doesn't provide any easy to use templates or tools for normal users to manage them. All you get is the little "security" tab in Folder Properties, which provides a maze of twisty little passages, all different and alike. Some software installers create "special" permissions that can cause issues, because creating, writing, and deleting files are 3 separate permissions. To make the issue more complex, each subfolder has the option of either inheriting all of its permissions from the parent folder, or being given a specific set. Thus when looking at a folder, you can't tell what security problems lurk beneath until you look deeper.
2) A destination target has changed from a file to a folder, or vice versa. This happens to me often because for example, whenever I update CygWin, it replaces some items that used to be files with folders. FFS refuses to overwrite a pre-existing file with a folder, and vice-versa, leading to an ffs_tmp error.
To answer your question about why .ffs_tmp files get created: In "fail-safe" mode (the default), FFS first copies a file to a .ffs_tmp copy on the destination. Then, after the copy is complete, it changes the name of the .ffs_tmp file to the correct name. This assures a safe transfer because if the system crashes in the middle of the copy, both the source and original destination are unmodified. Upon reboot, you'd have a partially copied .ffs_tmp file that you can delete. There is very little additional overhead in doing this; all it adds to the processing is a filename change. Side note -- If the destination drive is removable, be sure to enable "Quick Removal" in the disk properties... this causes more frequent flushing (aka Write-Through policy) of the buffer cache and file system metadata to the drive, which also improves integrity in the event of a system failure.
-JDB
1) (as Plerry just said) The security ACLs or rights are not permissive enough in the destination folder or specific files. Windows security settings can get out of whack, and Microsoft doesn't provide any easy to use templates or tools for normal users to manage them. All you get is the little "security" tab in Folder Properties, which provides a maze of twisty little passages, all different and alike. Some software installers create "special" permissions that can cause issues, because creating, writing, and deleting files are 3 separate permissions. To make the issue more complex, each subfolder has the option of either inheriting all of its permissions from the parent folder, or being given a specific set. Thus when looking at a folder, you can't tell what security problems lurk beneath until you look deeper.
2) A destination target has changed from a file to a folder, or vice versa. This happens to me often because for example, whenever I update CygWin, it replaces some items that used to be files with folders. FFS refuses to overwrite a pre-existing file with a folder, and vice-versa, leading to an ffs_tmp error.
To answer your question about why .ffs_tmp files get created: In "fail-safe" mode (the default), FFS first copies a file to a .ffs_tmp copy on the destination. Then, after the copy is complete, it changes the name of the .ffs_tmp file to the correct name. This assures a safe transfer because if the system crashes in the middle of the copy, both the source and original destination are unmodified. Upon reboot, you'd have a partially copied .ffs_tmp file that you can delete. There is very little additional overhead in doing this; all it adds to the processing is a filename change. Side note -- If the destination drive is removable, be sure to enable "Quick Removal" in the disk properties... this causes more frequent flushing (aka Write-Through policy) of the buffer cache and file system metadata to the drive, which also improves integrity in the event of a system failure.
-JDB
