Error Code 17: File exists [rename]

Get help for specific problems
Posts: 1
Joined: 14 Apr 2018

Post by wdavro • 14 Apr 2018, 23:32

I've been using FFS maybe 2 years between 4 different Ubuntu 16.04 systems and recently 1 Raspberry Pi3.
I have a bbackups folder on each computer except the pi.
I have samba running on them all and login to each using the local username on each. That user has full rights to the bbackups folder and all subfolders and files.

Nitely I backup each computer to it's own bbackup sub folder via rsync.
At the end of the backup script I chown +R bbackups to the local username and chmod +R bbackups to 770.

During the day, I mount the other computer drives using samba and I manually start FFS and two-way sync the bbackup folders between the different computers so each computer ends up with a backup of itself and all the other computers.
I'v been doing this for close to 2 years without any problems.

Since somewhere around v9.2 or 3 I've started getting lots of Error Code 17 errors on various, but different files.

I've attached an ffs text log file from today's sync showing all the errors.

I've only been using linux for a few years and am moderately capable but by no means an expert.

FFS used to work just fine but lately not so much.

I'm not sure what further info I should provide and I'd appreciate any help with this?
You do not have the required permissions to view the files attached to this post.

User avatar
Site Admin
Posts: 4955
Joined: 9 Dec 2007

Post by Zenju • 15 May 2018, 09:16

First step is to check if the target files really already exist as shown in the error messages. If yes, was the categorization shown in FFS's main dialog correct? Maybe these files were created externally after the comparison has run?

Posts: 1
Joined: 10 Jan 2019

Post by ddr2 • 10 Jan 2019, 15:29

I encountered this problem when the destination drive was a network share location and the destination files were edited on a Windows computer. In this case rsync running on Linux was unable to over-write the destination file with the new backup copy. Not sure exactly why, but this only occurred after someone on Windows went into the network share drive and made an edit to one of the files.