The daytime saving issue uncovered another problem.
I decided to sync again a whole directory of 17 Gb and 46000 files. Note >95%
of the files were actually the same, just the 1h difference.
Two problems:
1. The estimated time for completing was more than 1 day!
2. At some point the trash can got full up and the process halted. It seems a copy was being kept in the trash for each file that was being deleted.
I emptied the trash can and the process could continue, but could see that the copies in the trash can were created again.
3. I finally stopped freefilesync and copied one folder with 12000 items and 3.2 Mb. That
took 1 minute!
4. Then run freefilesync again and the sync completed in 1 more minute or so. At the end
I was asked to empty the trash can.
Should I have unset "Fail-safe file copy (recommended)" in this case? Would that have
solved both the problem of the trash can getting full up and of the long time to complete?
Problem with trash getting full up on linux
- Posts: 8
- Joined: 27 Jan 2009
- Posts: 8
- Joined: 27 Jan 2009
I'm using now the 6.6 version from the debian build (FreeFileSync_6.6_Debian_7.5_64-bit.tar.gz)
-
- Site Admin
- Posts: 7211
- Joined: 9 Dec 2007
> 1. The estimated time for completing was more than 1 day!
Statistics for remaining time in FFS are based on file size only. This has the side effect that deleting files creates a distortion, because this is seen as "no bytes copied", but it still takes some time.
> 2. At some point the trash can got full up and the process halted. It seems a copy was being kept in the trash for each file that was being deleted.
I emptied the trash can and the process could continue, but could see that the copies in the trash can were created again.
Not sure what the problem is: Are you expecting FFS to empty the trash automatically?
> 3. I finally stopped freefilesync and copied one folder with 12000 items and 3.2 Mb. That
took 1 minute!
What's the problem here?
> 4. Then run freefilesync again and the sync completed in 1 more minute or so. At the end
I was asked to empty the trash can.
What's the problem here?
> Should I have unset "Fail-safe file copy (recommended)" in this case? Would that have
solved both the problem of the trash can getting full up and of the long time to complete?
Maybe there is a misunderstanding: It's not FFS's job to empty the trash can. This should be handled by the OS and/or the user.
Statistics for remaining time in FFS are based on file size only. This has the side effect that deleting files creates a distortion, because this is seen as "no bytes copied", but it still takes some time.
> 2. At some point the trash can got full up and the process halted. It seems a copy was being kept in the trash for each file that was being deleted.
I emptied the trash can and the process could continue, but could see that the copies in the trash can were created again.
Not sure what the problem is: Are you expecting FFS to empty the trash automatically?
> 3. I finally stopped freefilesync and copied one folder with 12000 items and 3.2 Mb. That
took 1 minute!
What's the problem here?
> 4. Then run freefilesync again and the sync completed in 1 more minute or so. At the end
I was asked to empty the trash can.
What's the problem here?
> Should I have unset "Fail-safe file copy (recommended)" in this case? Would that have
solved both the problem of the trash can getting full up and of the long time to complete?
Maybe there is a misunderstanding: It's not FFS's job to empty the trash can. This should be handled by the OS and/or the user.
- Posts: 8
- Joined: 27 Jan 2009
> 1. The estimated time for completing was more than 1 day!
Statistics for remaining time in FFS are based on file size only. This has the side effect that deleting files creates a distortion, because this is seen as "no bytes copied", but it still takes some time.
> 2. At some point the trash can got full up and the process halted. It seems a copy was being kept in the trash for each file that was being deleted.
I emptied the trash can and the process could continue, but could see that the copies in the trash can were created again.
Not sure what the problem is: Are you expecting FFS to empty the trash automatically?
> 3. I finally stopped freefilesync and copied one folder with 12000 items and 3.2 Mb. That
took 1 minute!
What's the problem here?
> 4. Then run freefilesync again and the sync completed in 1 more minute or so. At the end
I was asked to empty the trash can.
What's the problem here?
> Should I have unset "Fail-safe file copy (recommended)" in this case? Would that have
solved both the problem of the trash can getting full up and of the long time to complete?
Maybe there is a misunderstanding: It's not FFS's job to empty the trash can. This should be handled by the OS and/or the user.Zenju
I finally stopped freefilesync and copied one folder with 12000 items and 3.2 Mb. That
took 1 minute!
What's the problem here?
The problem is the difference of time. It was taking hours with FFS and was copied in minutes by the OS. What's the reason of such a huge difference? Just the fact that FFS was making a copy in the trash of every file that had to be overwritten (nearly all in this case)? Is there any way I can avoid FFS making the trash copies in the cases in which I'm forced to overwrite many files because of the daytime saving problem?
Regarding emptying the trash can, it would make sense having the option of
getting it emptied in case of FFS jobs that take such a huge amount of time.
-
- Site Admin
- Posts: 7211
- Joined: 9 Dec 2007
> Just the fact that FFS was making a copy in the trash of every file that had to be overwritten (nearly all in this case)?
Probably. In your test you only copied files, while FFS had to copy and move to the trash. So it's possible that moving these file to the trash was the actual slow operation.
> having the option of getting it emptied in case of FFS
You can set deletion handling to "permanent" in sync settings and simply avoid using the trash.
Probably. In your test you only copied files, while FFS had to copy and move to the trash. So it's possible that moving these file to the trash was the actual slow operation.
> having the option of getting it emptied in case of FFS
You can set deletion handling to "permanent" in sync settings and simply avoid using the trash.
