Ok So I'm really confused about how FFS regards the jobs location.
Today I created 2 batch jobs and after restarting FFS they weren't in the list.
I began to investigate and realised that I only have 28 of 33 jobs showing in the window and the 2 are definitely missing.
I moved all files to a new folder and then opened that folder - I can choose the job there but nothing is in the list except the one I choose. I can delete it from the window (thinking it would delete from the disk but it doesn't.
I then moved all files back to the normal location and the list does not fill out.
I tried to find out where to set the folder to scan but can't seem to find it.
The only way I could populate the list was to hit "open" and choose every single job and the list populates then.
So I'm not sure what is going on, why my 2 created jobs today failed to show up after a restart and why other jobs were missing.
It appears the list in FFS is a virtual list not connected to the folder other than virtually as a job that only shows up if it's been done once. Deletion doesn't cause deletion of the job in the folder but creation does.
I am confused by this kind of strategy and I don't feel I can trust what I see now in the list are all my jobs.
Is there no way FFS can just simply mirror what it finds in the folder without all this jumping through hoops?
Have I stumbled on a problem or did I do something wrong?
Jobs confusion
- Posts: 29
- Joined: 13 Aug 2019
-
- Posts: 3611
- Joined: 11 Jun 2019
That is the correct behavior. Deleting from the list is not deleting from disk. FFS doesn't automatically add jobs to the list just because they are in the "default" folder, and there isn't technically a "default" folder. It's like Word; just because you download a word document to your Documents folder doesn't mean Word is going to put it in the recent files list. This isn't usually an issue because you create jobs in FFS, then when saving them, it just opens up the last-used location for your config files where it saves it and adds it to the list. They are more like shortcuts to config files
- Posts: 29
- Joined: 13 Aug 2019
Understood however, not knowing this "virtual" system was a little bit of a problem.
It doesn't explain though how Created 2 new jobs and they didn't show up. In fact until I started to investigate I noticed that it would not display more than 28 and I had 33 jobs.
The other problem was that some time ago I made a suggestion that FFS has a folder system in the config area so that we can separate certain jobs out. Can't remember who replied but the suggestion was that it could be kept in a separate folder locally and then you can open jobs in that folder.
However, now this really doesn't work it causes more confusion as when you do that the jobs appear in the list (as you'd expect) only now you have absolutely no idea where they came from as there is no indication that these were loaded from a different folder. A tag would be nice that might indicate that.
The other problem is that in order to use even the suggested system I have to delete the jobs in the list and load a new set that I'm doing and all the data for "last sync" is now lost when I go back to loading other jobs.
It would be nice to see the ability to keep that data - does anyone know where this is stored - I could at least do a quick and dirty back up of that.
It doesn't explain though how Created 2 new jobs and they didn't show up. In fact until I started to investigate I noticed that it would not display more than 28 and I had 33 jobs.
The other problem was that some time ago I made a suggestion that FFS has a folder system in the config area so that we can separate certain jobs out. Can't remember who replied but the suggestion was that it could be kept in a separate folder locally and then you can open jobs in that folder.
However, now this really doesn't work it causes more confusion as when you do that the jobs appear in the list (as you'd expect) only now you have absolutely no idea where they came from as there is no indication that these were loaded from a different folder. A tag would be nice that might indicate that.
The other problem is that in order to use even the suggested system I have to delete the jobs in the list and load a new set that I'm doing and all the data for "last sync" is now lost when I go back to loading other jobs.
It would be nice to see the ability to keep that data - does anyone know where this is stored - I could at least do a quick and dirty back up of that.
-
- Posts: 3611
- Joined: 11 Jun 2019
Basically the issue is that the current design isn't friendly to a large number of jobs. There are colored backgrounds, but no way to organize it besides alphabetically.
- Posts: 29
- Joined: 13 Aug 2019
Hence my suggestions some time ago.
I see last sync data is stored in GlobalSettings.xml maybe I could preserve this data and restore it when I reinstate those backups in my list.
Not ideal but it'll have to do for now.
I see last sync data is stored in GlobalSettings.xml maybe I could preserve this data and restore it when I reinstate those backups in my list.
Not ideal but it'll have to do for now.
-
- Posts: 2288
- Joined: 22 Aug 2012
The GlobalSettings.xml file is read upon opening an FFS instance and written when an FFS instance is closed (in a regular fashion).
The problem seems to be (?) that multiple instances of FFS are mutually unaware of the changes other instances (intend to) make to the FFS configuration as saved in GlobalSettings.xml.
Thus, upon closing the last of parallel open FFS instances, that instance will write a GlobalSettings.xml, applying its relevant changes to the configuration since opening that instance; thereby overwriting any GlobalSettings.xml-file that any other of the parallel open FFS instances may have written when those instances closed.
The problem seems to be (?) that multiple instances of FFS are mutually unaware of the changes other instances (intend to) make to the FFS configuration as saved in GlobalSettings.xml.
Thus, upon closing the last of parallel open FFS instances, that instance will write a GlobalSettings.xml, applying its relevant changes to the configuration since opening that instance; thereby overwriting any GlobalSettings.xml-file that any other of the parallel open FFS instances may have written when those instances closed.
- Posts: 29
- Joined: 13 Aug 2019
I don't understand the relevance of this answer. This isn't about "multiple instances of FFS running" I don't do that.
I really don't understand why we couldn't have a simple logical management of jobs such as a proper representation of a static job folder and a scan to show the jobs in that folder instead of a confusing virtual system that loses data the minute you try to manage or work around the system to suit.
We could then simply have last sync data recording what is going on with jobs in that folder and no danger of losing the data. A folder system to help with separating the jobs or "more colours" no "8 isn't enough"
The system may not be "friendly to large amount of jobs " but I fail to see why that is so.
This is designed for syncing . I happen to have ditched all non-volatile external media storage simply because it's a nightmare and has never caught up with the capacities need".
I therefore have specific backups that get sent to multiple hard drives and locations and I do section of backup depending on what locations / media are on line at the time plus many other complexities I won't go into.
It is a nightmare to manage this and a workaround has failed because I like to know that last sync information so If I end up separating certain jobs into separate LOCAL folders and loading them in, I HAVE to delete what's in the list otherwise there's no clear way of knowing next time which folder they came from.
This loses me the colouring AND the last sync data. There actually isn't a workaround other than my preserving that xml file and replacing it when I restore the list each time and even then under that workaround I'd have to actually edit it to add the stuff I did from the separate folder.
I'm sure somehow there is method in this madness and there are good reasons why it is done this way but from my point there is little value for me, I'd much rather the logical "this is the working folder and here are the jobs in it." ... simples.
... and don't get me wrong, FFS is a fantastic piece of software but there are flaws like this that make it quite trying.
I really don't understand why we couldn't have a simple logical management of jobs such as a proper representation of a static job folder and a scan to show the jobs in that folder instead of a confusing virtual system that loses data the minute you try to manage or work around the system to suit.
We could then simply have last sync data recording what is going on with jobs in that folder and no danger of losing the data. A folder system to help with separating the jobs or "more colours" no "8 isn't enough"
The system may not be "friendly to large amount of jobs " but I fail to see why that is so.
This is designed for syncing . I happen to have ditched all non-volatile external media storage simply because it's a nightmare and has never caught up with the capacities need".
I therefore have specific backups that get sent to multiple hard drives and locations and I do section of backup depending on what locations / media are on line at the time plus many other complexities I won't go into.
It is a nightmare to manage this and a workaround has failed because I like to know that last sync information so If I end up separating certain jobs into separate LOCAL folders and loading them in, I HAVE to delete what's in the list otherwise there's no clear way of knowing next time which folder they came from.
This loses me the colouring AND the last sync data. There actually isn't a workaround other than my preserving that xml file and replacing it when I restore the list each time and even then under that workaround I'd have to actually edit it to add the stuff I did from the separate folder.
I'm sure somehow there is method in this madness and there are good reasons why it is done this way but from my point there is little value for me, I'd much rather the logical "this is the working folder and here are the jobs in it." ... simples.
... and don't get me wrong, FFS is a fantastic piece of software but there are flaws like this that make it quite trying.
-
- Site Admin
- Posts: 7052
- Joined: 9 Dec 2007
I think the solution to all problems is to move the configuration list data out of GlobalSettings.xml, and make it a separate configuration file that is:
• Shared by all running FFS instances
• updated immediately, not just during FFS exit
=> The data shown by each FFS instance may be a bit stale at times (I don't think implementing dynamic updating is worth the increase in program complexity), but it would be correct once FFS is restarted.
On top of that, FFS should not lose track of config files that are moved/renamed outside of FFS
• FFS could save file IDs for config files (possible on Windows at least, but not on Linux/macOS), that would allow to detect moves inside a disk volume.
Restrictions:
The config handling explained by Plerry is a severe issue for any app that allows running multiple instances.
So there still would be a conflict for the rest of GlobalSettings.xml.
I'll have to make a review and see if the above handling should be applied to other settings, too (e.g. warnings), while most of the graphical layout config doesn't matter much and may be overwritten by the last FFS instance closing.
• Shared by all running FFS instances
• updated immediately, not just during FFS exit
=> The data shown by each FFS instance may be a bit stale at times (I don't think implementing dynamic updating is worth the increase in program complexity), but it would be correct once FFS is restarted.
On top of that, FFS should not lose track of config files that are moved/renamed outside of FFS
• FFS could save file IDs for config files (possible on Windows at least, but not on Linux/macOS), that would allow to detect moves inside a disk volume.
Restrictions:
The config handling explained by Plerry is a severe issue for any app that allows running multiple instances.
So there still would be a conflict for the rest of GlobalSettings.xml.
I'll have to make a review and see if the above handling should be applied to other settings, too (e.g. warnings), while most of the graphical layout config doesn't matter much and may be overwritten by the last FFS instance closing.
- Posts: 29
- Joined: 13 Aug 2019
I appreciate that there has been a shift to discussing "multiple instances " of FFS but it isn't the problem I have.
1st problem - I created 2 jobs and they simply disappeared. Single session only and I tested this a few times and it just seemed to only allow 28 jobs till I opened the folder, highlighed everything and let it think all those jobs were to be done. The list then had my 33 jobs in it.
2nd problem:
Many months ago I posted a suggestion / request that we are allowed a folder structure in the "list" what FFS heads a configuration on the left, for organisational purposes. Wrongly I assumed this was simply a representation of a folder where all my jobs were stored and mirrored that so that misunderstanding caused me some heartache.
The reply (pierry) I believe was to tell me it's easy to store separate jobs in a sub folder and open those when I need to run a certain set of jobs. I thought this was a good idea because as explained because of my initial misunderstanding.
The fact that it is virtual folder that just lists jobs that have been run, however, makes this idea a non- started as after I had done it the list just showed the job itself but with no indication of which ones were from the sub folder or where they originated from. Only way to find out is a laborious click on each on to view its origin
Next Idea I had once I twigged all too late that this is not a true representation of the contents of my jobs folder was to delete ALL jobs - load the jobs I needed from the sub folder and then restore the main backups.
So I lost all my colouring and all my last sync data.
I don't have a solution to making the management of several jobs without confusing myself other than to do what I have been doing is trying to put drives, names and destinations in the file name and that makes it quite easy to lose track of some jobs.
The local sub folder idea is dead in the water I think but again I do find it strange that the left hand side is not just an explorer window to a default jobs folder. Would be so simple from a user's point of view but from the developer perhaps there are many other reasons.
1st problem - I created 2 jobs and they simply disappeared. Single session only and I tested this a few times and it just seemed to only allow 28 jobs till I opened the folder, highlighed everything and let it think all those jobs were to be done. The list then had my 33 jobs in it.
2nd problem:
Many months ago I posted a suggestion / request that we are allowed a folder structure in the "list" what FFS heads a configuration on the left, for organisational purposes. Wrongly I assumed this was simply a representation of a folder where all my jobs were stored and mirrored that so that misunderstanding caused me some heartache.
The reply (pierry) I believe was to tell me it's easy to store separate jobs in a sub folder and open those when I need to run a certain set of jobs. I thought this was a good idea because as explained because of my initial misunderstanding.
The fact that it is virtual folder that just lists jobs that have been run, however, makes this idea a non- started as after I had done it the list just showed the job itself but with no indication of which ones were from the sub folder or where they originated from. Only way to find out is a laborious click on each on to view its origin
Next Idea I had once I twigged all too late that this is not a true representation of the contents of my jobs folder was to delete ALL jobs - load the jobs I needed from the sub folder and then restore the main backups.
So I lost all my colouring and all my last sync data.
I don't have a solution to making the management of several jobs without confusing myself other than to do what I have been doing is trying to put drives, names and destinations in the file name and that makes it quite easy to lose track of some jobs.
The local sub folder idea is dead in the water I think but again I do find it strange that the left hand side is not just an explorer window to a default jobs folder. Would be so simple from a user's point of view but from the developer perhaps there are many other reasons.
- Posts: 16
- Joined: 10 Jun 2019
As a new (returning from the past) user I'm happy that there is some discussion about organizing the synchronization jobs. I have been using another synchronization software for the last few years where this facility existed and it did make my life easier as I have around 20 different synchronization tasks that I do, some of them intra-day and others at different times. I too put drives, names and destinations in the file name as a solution, but really it's not at all efficient or very convenient.
Hopefully the developer will include task organization in some future version of the product.
Hopefully the developer will include task organization in some future version of the product.
- Posts: 41
- Joined: 10 Jul 2016
I would also appreciate an extraction of the data from the "GlobalSettings.xml".
My problem in this context is the following:
I have a folder "D:\Tools" on machine1, where FreeFileSync is also located in its own folder ("D:\Tools\FreeFileSync") as a portable 'installation'.
The folder "D:\Tools" is completely synchronized with a USB stick by FreeFileSync ('TwoWay'). Therefore the FreeFileSync folder will be synchronized as well.
This stick is then also synchronized with FreeFileSync with computer2 (also 'TwoWay'), also there everything is in the folder "D:\Tools".
So I only have to take care of one FreeFileSync folder.
On machine1 and machine2 I also have other different jobs that I use FreeFileSync from "D:\Tools\FreeFileSync".
Although I never have more than one FreeFileSync instance running at the same time, I still have the problem that the "GlobalSettings.xml", and therefore also the data of the jobs, contain different data from computer to computer.
So I have a synchronization conflict with the "GlobalSettings.xml", which FreeFileSync also shows me cleanly.
Only unfortunately I would have to merge now the contents of the "GlobalSettings.xml". Simply overwriting is not enough to get e.g. all LastSync data correctly.
Maybe it is necessary, like Zenju suggested, to put these LastSync data (and maybe more?) per job into single files. These can then be synchronized cleanly.
My problem in this context is the following:
I have a folder "D:\Tools" on machine1, where FreeFileSync is also located in its own folder ("D:\Tools\FreeFileSync") as a portable 'installation'.
The folder "D:\Tools" is completely synchronized with a USB stick by FreeFileSync ('TwoWay'). Therefore the FreeFileSync folder will be synchronized as well.
This stick is then also synchronized with FreeFileSync with computer2 (also 'TwoWay'), also there everything is in the folder "D:\Tools".
So I only have to take care of one FreeFileSync folder.
On machine1 and machine2 I also have other different jobs that I use FreeFileSync from "D:\Tools\FreeFileSync".
Although I never have more than one FreeFileSync instance running at the same time, I still have the problem that the "GlobalSettings.xml", and therefore also the data of the jobs, contain different data from computer to computer.
So I have a synchronization conflict with the "GlobalSettings.xml", which FreeFileSync also shows me cleanly.
Only unfortunately I would have to merge now the contents of the "GlobalSettings.xml". Simply overwriting is not enough to get e.g. all LastSync data correctly.
Maybe it is necessary, like Zenju suggested, to put these LastSync data (and maybe more?) per job into single files. These can then be synchronized cleanly.
