[Merged] PR#1148: Backup files policy

Merged, abandoned or rejected pull requests are moved here to clear the main Pull Requests forum.
plgarcia
Posts: 310
Joined: Wed Jun 17, 2015 9:47 pm
Location: Near Paris (France)

Re: PR#1148: Backup files policy

Post by plgarcia »

Hello,
Many google drive updates have been made since the problem has been encountered. And I think Google has solved the problem.

What is important is then the functionality added with this PR, and the warning reported to the user when a problem occurs.

I think this problem can occur also if the access rights of the backup are changed, of the file is locked by whatever software and cannot be deleted.

I checked my code and I will change it to ensure the file is saved as much as possible, even if a problem occus with a backup that cannot be deleted what is not crucial.

Regards
Last edited by plgarcia on Fri Feb 23, 2018 3:29 pm, edited 1 time in total.
triplus
Veteran
Posts: 9471
Joined: Mon Dec 12, 2011 4:45 pm

Re: PR#1148: Backup files policy

Post by triplus »

sgrogan wrote: Tue Feb 20, 2018 9:22 pm I can provide a build.
Thanks!

@plgarcia

I don't have much free time for the next day or two. Just a quick response. Therefore you say you don't detect the original issue anymore (testing the provided build). In addition it looks like Google fixed it on their side too? Good. As for the PR itself. It therefore does two things?
  • Pop-up notification if the save fails.
  • Different backup file name strategy with time stamp used?
Beyond that it doesn't touch current FC save functionality?

If that is correct and you want my opinion (without in depth thinking if any possible potential problems exist using such naming scheme). If we are going to change the current way of handling backup file names. To make it more user readable.
  • Time stamp could be appended to the name instead? And a standard extension like for example .FCBak to be used.
  • Usually when i use a time stamp feature. I tend to use the "human readable" format. For example using Jan instead of 01. Different places around the world use different convention for what comes first. Month or the day.
  • I guess there should be more user feedback on this. And to decide what makes more sense. Postponing this feature to FreeCAD 0.18 could make sense?
Beyond stating this i am OK with whatever happens next.
GeneFC
Veteran
Posts: 5373
Joined: Sat Mar 19, 2016 3:36 pm
Location: Punta Gorda, FL

Re: PR#1148: Backup files policy

Post by GeneFC »

triplus wrote: Thu Feb 22, 2018 2:52 pm Time stamp could be appended to the name instead? And a standard extension like for example .FCBak to be used.
I agree. I do not like to create a huge number of new extension types in Windows. A single extension such as .FCBak would be fine.
triplus wrote: Thu Feb 22, 2018 2:52 pm Usually when i use a time stamp feature. I tend to use the "human readable" format. For example using Jan instead of 01. Different places around the world use different convention for what comes first. Month or the day.
I believe it has become pretty standard to use yyyymmdd for dates that need to be sorted. I like the human readable versions for a lot of things, but they don't sort well.

Finally, I cannot imagine how someone could use 30 backups without detailed notes on what changed with each version. :roll:

Gene
plgarcia
Posts: 310
Joined: Wed Jun 17, 2015 9:47 pm
Location: Near Paris (France)

Re: PR#1148: Backup files policy

Post by plgarcia »

Ok I change the extension.
name.timestamp.FCBak

The format yyyymmdd-HHmmss sorts right. That is why I have chosen this format.

Agreed for 30 it is quite a lot. I did that because some of my model were garbled because of topological problems. So I was saving very often. Many archives were giving me more chances to find a non-garbled model.


Pascal Garcia
Last edited by plgarcia on Fri Feb 23, 2018 3:29 pm, edited 1 time in total.
chrisb
Veteran
Posts: 53786
Joined: Tue Mar 17, 2015 9:14 am

Re: PR#1148: Backup files policy

Post by chrisb »

A common use case for me is to know that some steps back I have a file I want to recover. Usually I don't want to keep the current file because something went utterly wrong.
I open a commandline and list the backup files by date. Then I copy the most recent to the current file and check if it is ok. If not I repeat the last commandline and change just the number of the source file. I continue until I have found the correct file.
Having the obsolete timestamp in the filename would make this difficult because I have to type much more, and please consider, that this is in a situation where I am upset enough, because some of the work gets lost.

I would propose using placeholders like e.g. the path workbench does. There could be placeholders like
%p for the path, enabling the user to have the backup files in the same or in a dedicated directory
%d, %m, %y for day, month and year, enabling the user to control the date format
%f for the raw filename prefix, enabling to have the same backup file set for different files
%n for a number incremented one by one as we have it now,
A Sketcher Lecture with in-depth information is available in English, auf Deutsch, en français, en español.
plgarcia
Posts: 310
Joined: Wed Jun 17, 2015 9:47 pm
Location: Near Paris (France)

Re: PR#1148: Backup files policy

Post by plgarcia »

I cannot push the commit.
fatal: AggregateException encountered.

I have to sort that.
plgarcia
Posts: 310
Joined: Wed Jun 17, 2015 9:47 pm
Location: Near Paris (France)

Re: PR#1148: Backup files policy

Post by plgarcia »

Still have problem with git asking always the login and password, and I do not understand the cause. Stupid problem of credential solved.
Never mind, changes are pushed. They do not compile on windows because of server installation problems, not because of the code.
ERROR: FreeCADLibs_11.5.1_x64_VC12.7z
Can not open the file as archive
Here is an example, with old archives partially deleted to maintain the 30 archives parameterized. Any other remarks ?

For chrisb proposal, it is to be discussed, and more complex. I feel having the ability to put archives in a sub folder is a good idea.

I found a new interest to have always a different name for the archive. One can find in google drive bin all versions since last time bin has been emptied.

Capture8.PNG
Capture8.PNG (83.44 KiB) Viewed 2979 times
Last edited by plgarcia on Sat Feb 24, 2018 8:38 am, edited 1 time in total.
plgarcia
Posts: 310
Joined: Wed Jun 17, 2015 9:47 pm
Location: Near Paris (France)

Re: PR#1148: Backup files policy

Post by plgarcia »

chrisb wrote: Thu Feb 22, 2018 7:16 pm ...
I open a commandline and list the backup files by date. Then I copy the most recent to the current file and check if it is ok. If not I repeat the last commandline and change just the number of the source file. I continue until I have found the correct file.

Having the obsolete timestamp in the filename would make this difficult because I have to type much more, and please consider, that this is in a situation where I am upset enough, because some of the work gets lost.
...
Have you a script to do that? With a script you can do almost as well and simpler. A restoreLast.bat or restorLast.sh would do it automatically, without sacrifying the archives as you do.

The file revert function could also be improved, adding a list when cliquing on revert with choices "revert to last" and the list of the archives available.

When a model is garbled because of software problem I copy and paste in a new document what works quite fine most of the time. For human mistakes it does not!
I would propose using placeholders like e.g. the path workbench does. There could be placeholders like
%p for the path, enabling the user to have the backup files in the same or in a dedicated directory
%d, %m, %y for day, month and year, enabling the user to control the date format
%f for the raw filename prefix, enabling to have the same backup file set for different files
%n for a number incremented one by one as we have it now,
That is not a big issue but needs to add parameters to the software. I am not ready to do yet as I do not know that part of the software.
chrisb
Veteran
Posts: 53786
Joined: Tue Mar 17, 2015 9:14 am

Re: PR#1148: Backup files policy

Post by chrisb »

plgarcia wrote: Fri Feb 23, 2018 3:47 pm Have you a script to do that? With a script you can do almost as well and simpler. A restoreLast.bat or restorLast.sh would do it
automatically, without sacrifying the archives as you do.
I don't have a script because there is not much to gain. A script needs the file name as well and my shell makes the expansion to .fcstd or .FCStd itself. I sacrifice the archives on purpose. If they are garbled I don't need them; the other option would be to delete them right after. I am a friend of a big number of backup files so cleaning up every now and then is a good thing anyway. Besides that, it's been a long time since I had to reset a project like that.
That is not a big issue but needs to add parameters to the software. I am not ready to do yet as I do not know that part of the software.
Perhaps the Tools->Parameters can help. There seems to be a uniform way to input the presets from a user's side and I guess there is a uniform way to read them from program side.
A Sketcher Lecture with in-depth information is available in English, auf Deutsch, en français, en español.
plgarcia
Posts: 310
Joined: Wed Jun 17, 2015 9:47 pm
Location: Near Paris (France)

Re: PR#1148: Backup files policy

Post by plgarcia »

chrisb wrote: Fri Feb 23, 2018 4:28 pm Besides that, it's been a long time since I had to reset a project like that.
Within the last months, FreeCAD has clearly improved for that. I was keeping files errored that are now not showing the problems anymore.
Perhaps the Tools->Parameters can help.
Yes it is the way, but I am spending quite some time on colors management, and I would like to finish that before investing in more areas.

And anyway, no use to develop without having some kind of agreement on what to do if we want to have a chance to have the change accepted and integrated in the software.
Post Reply