gns3 developers should never implement a change that puts timestamps in gns3 config files

[josephmhiggins]

Embedding a timestamp in any of the gns3 config files (in gns3 2.x the config files are "gns3_server", "gns3_gui" and "gns3_controller") would cause a nightmare.

Do not embed timestamps in the the gns3 config files.

So, I will explain. I have a pre-gns3 and a post-gns3 in my powershell script to start gns3.
Long story, but I partially explain here before I explain it another thread I will post for a requested enhancement.
My post-gns3 backs up all the gns3 config files and the gns3 log files (dealing with the gns3 log files is another thread that I am not prepared to write up now).
My post-gns3 causes many, many unnecessary files to be backed up. I figured out how to solve this problem around 8 months ago and promptly forget the solution.

But the solution is found in "Windows PowerShell Best Practices" by Ed Wilson, Chapter 1. The book text, follows, and is tangential to how I will solve my problem - if and only if no timestamps are included in the config files - "Not every device is backed up each day. I have no way of knowing what the latest time stamp will be in each recursive directory"

For my script:
the file hashes of the config files can be determined in pre-gns3 and then calculated post-gns3. Consequently, I will only have to backup the config files that have changed.

This is a very, veryt big deal to me.

[josephmhiggins]

Yeah. I am not recommend closing this. The gns3 developers should never put timestamps in those config files.

[spikefishjohn]

So basically you want someone to redesign gns3 so time stamps aren’t in the config files to make it easier for you to detect when you need to do a backup?

I don’t think you’ve made a very good case for this.

That being said the config files are all json. You can filter out the time stamps via a json filter then compare that hash afterwards.

https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/parsing-json-with-powershell/ba-p/2768721

[josephmhiggins]

The timestamps are not in the config files.
The developers would have to redesign gns3 to put them in the config files.
The config files are not json only.
gns3_server.ini is a "section" based configuration file, like so:
[Server]
key = value

Putting timestamps in configuration files is a complete nightmare.
Putting timestamps in a configuration file that has not changed, except for the new timestamp, is a completely nonsensical design.

[spikefishjohn]

Oh yeah. I was thinking about the controller config.

Where is the timestamp in the server ini file?

I mean same thing could apply for a .ini. Parse out the dynamic stuff then diff that.

https://techgenix.com/reading-an-ini-file-into-powershell/

[josephmhiggins]

There is no timestamp.

1. This thread is designed to block the gns3 developers from implementing a change that puts a timestamp in it.
2. re: getting key values from json and the controller conig file, yeah, wow, that is easy to do. I made a pot of coffee and was expecting to take 3 days how to figure out how to do it. It took me 30 seconds with a powershell cmdlet, convertfrom-json. I almost fell out of my couch when i saw how easy it was to do.
3. re: the section based config file (part one)- that was time consuming to figure out. The primary roadblock was I recognized that was a standard design in linux files found in base classes. So, I spend an hour or two trying to google the standard python template that python programmers used to access the key value pairs and to find out if there were any rules for that type of template. With that template, I left alone a warning to the developers NOT to reuse a key name - even if the key name was in another section. I trusted that the gns3 developers would know enough to do that.
4. re: the section based config file (part two) - In powershell, i figure one way to do it; there is more than one way to do it. That took me 90 minutes. But.........between my gns3 2.2.31 and gns3 2.2.34, the gns3 developers changed the template. The template is not documented so they are allowed to change it. This is a whole big thing. I have discussed this. The actual powershell code was left incomplete because the gns3 developers changed the template. As far as techgnix is concerted, there are 2 options programmers use:
   1. read in one line at a time because the file could be one hundred million lines long, or
   2. read the whole file in and use regex to grab the data

This is incomplete and a mess (because I just started to learn Visual Studio yesterday), but it was going to be my template and something in the code works:

Oh, I had to delete the code because github wants to reformat it and I do not know how to upload literal text to a post and I do not have the time to figure it out.

My code chose option ii because I know the file is less than 100 lines.

[josephmhiggins]

the timestamps are not a worry anymore, per se, because the gns3_gui has temporal values in it, i.e.
"geometry":
"recentprojects"

...so I will just deal with it, that they are in there.

putting things like, possibly the history of host binding, hidden away in the registry or encrypted somewhere would be a real pain.