Issues 1665 & 1666; Symbolic links & backups

Here's the place for discussion related to coding in FreeCAD, C++ or Python. Design, interfaces and structures.
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
triplus
Veteran
Posts: 9471
Joined: Mon Dec 12, 2011 4:45 pm

Re: Issues 1665 & 1666; Symbolic links & backups

Post by triplus »

chrisb wrote: Mon Sep 04, 2017 6:10 am The behaviour described in the OP is rather the behaviour of a hard link (which I have never seen in all my life, which implies that I never use them).
FreeCAD overwriting a symbolic link is a bug (hence the issue report).

P.S. Therefore we actually don't have to go into in depth discussions on why would one use a symbolic link. Regardless of the outcome of such debate FreeCAD overwriting a symbolic link would still be a bug.
wmayer
Founder
Posts: 20243
Joined: Thu Feb 19, 2009 10:32 am
Contact:

Re: Issues 1665 & 1666; Symbolic links & backups

Post by wmayer »

In testing this, I noticed something else I hadn't expected: The most recent backup has the largest number. That is to say; .fcstd1 is older than .fcstd2; I can think of reasons it was implemented like this, but I find it odd from a user perspective. I might be alone in that though.
From developer's point of view it makes sense as you can consider it as a revision number of a VCS. But in fact the reality is a bit different and the creation of backup files follows this strategy:
  • create backup files with incremented numbers
  • once the limit of backup files is reached it searches for the oldest files and overwrites it. So, you can end up with backup files where the latest version has the suffix 1 and the second latest the suffix 10.
So, after all the only relevant information is the creation date and not the suffix number. The whole point of doing it this way is efficiency and reliability because this approach never has to rename an existing file. Following your approach at some point you have to rename all existing backup files in order to keep suffix name consistent with creation date but then reliability sinks dramatically.

Assuming the probability of a successful renaming of a backup file is 99% then the chance that renaming 10 backup files still succeeds is only around 90% (=0.99^10). And this is not just hypothetical because in practise it can happen quite easily to make renaming a file fail, e.g. when any other process like a virus scanner accesses the file.
Also, it turns out that FreeCAD can't open its own backup files. That seems broken too. I have to rename the file to open it.
This is done on purpose. The whole point of a backup is that you can switch back to a certain version at any time (at least for a certain time frame) and therefore it shouldn't happen that you overwrite it by accident just because you loaded it directly into FreeCAD, did some changes and pressed the Save button.

Forcing the user to rename a file gives him the chance to think about what he is doing and if the file is really important that he makes a real backup file and saves it to an external location.
I like this idea. Not for the reasons in the issue, but because I'd like to be able to exclude a specific folder from by normal backup routine; there is no way to de-duplicate a compressed file.
Separating backup from normal files basically means that there can only be a single directory where backup files should go to. But this makes the whole concept of backup files useless as it leads to a massive loss of data.

Example:
You save a project in directory A which then puts the backup files to directory B. At a later point you create a new project which (by accident or on purpose) has the same name as in A and save it to directory C. So, this way you may lose the backup file corresponding to the project in directory A.

Summary:
I partially agree on point 1 and 4 of your proposal but highly disagree on the rest. The rollback function, however, should guarantee not to directly overwrite the backup file.
chrisb
Veteran
Posts: 53930
Joined: Tue Mar 17, 2015 9:14 am

Re: Issues 1665 & 1666; Symbolic links & backups

Post by chrisb »

wmayer wrote: Mon Sep 04, 2017 12:01 pm This is done on purpose. The whole point of a backup is that you can switch back to a certain version at any time (at least for a certain time frame) and therefore it shouldn't happen that you overwrite it by accident just because you loaded it directly into FreeCAD, did some changes and pressed the Save button.
It would be great if FreeCAD would allow reading but prohibit saving of a backup file. "Save as" could be allowed.
A Sketcher Lecture with in-depth information is available in English, auf Deutsch, en français, en español.
Sam
Posts: 177
Joined: Sun Mar 20, 2016 6:19 pm

Re: Issues 1665 & 1666; Symbolic links & backups

Post by Sam »

wmayer wrote: Mon Sep 04, 2017 12:01 pm I partially agree on point 1 and 4 of your proposal but highly disagree on the rest.
You say a lot of things that make sense. And I agree. Let me ask this:

Are you saying that a word censored solution for the other points is unacceptable, or do you find the concepts fundamentally abhorrent?
wmayer
Founder
Posts: 20243
Joined: Thu Feb 19, 2009 10:32 am
Contact:

Re: Issues 1665 & 1666; Symbolic links & backups

Post by wmayer »

Are you saying that a word censored solution for the other points is unacceptable, or do you find the concepts fundamentally abhorrent?
Point 3 and 5 are more or less only personal taste but has no technical benefit but it's even a regression. And with the implementation of a rollback function then from a user point of view it anyway doesn't matter how the suffix number correlates to the creation date.
Furthermore the rollback function automatically solves point 2 without the risk of overwriting the backup file (in case of correct implementation). About point 3 I already wrote the possibility of a loss of data increases and another reason not to do it again is efficiency. On Windows HD partitions start with a letter and there moving a file by renaming doesn't work across different partitions. So, this means if you want to move a file you have to copy it to the new location and delete it from the old location.
Sam
Posts: 177
Joined: Sun Mar 20, 2016 6:19 pm

Re: Issues 1665 & 1666; Symbolic links & backups

Post by Sam »

I've thought about what you said, and looked at how some other software handles this, and I agree agree with you.

I was thinking of ways to mitigate the issues you raised. I have some ideas, but all of them fall short on the manual usability front and create management issues that I can't be bothered dealing with for so little gain.

I'll get around to replying with an updated proposal soonish.

An idle thought; I don't know if I'm ignorant, but shouldn't a filename and/or path be some kind of utf8 qstring, not std::string?
User avatar
flachyjoe
Veteran
Posts: 1869
Joined: Sat Mar 31, 2012 12:00 pm
Location: Limoges, France

Re: Issues 1665 & 1666; Symbolic links & backups

Post by flachyjoe »

- Flachy Joe -
Image
User avatar
adrianinsaval
Veteran
Posts: 5541
Joined: Thu Apr 05, 2018 5:15 pm

Re: Issues 1665 & 1666; Symbolic links & backups

Post by adrianinsaval »

flachyjoe wrote: Thu Jun 16, 2022 8:22 pm Hi !

git commit 5ba4abb
Very interesting! doesn't this save backups in the link target location rather than the link location? Will you be making a PR for this?
User avatar
flachyjoe
Veteran
Posts: 1869
Joined: Sat Mar 31, 2012 12:00 pm
Location: Limoges, France

Re: Issues 1665 & 1666; Symbolic links & backups

Post by flachyjoe »

Hi,

Backup file is saved in link target directory as mentioned in bug report
triplus wrote:Expected behaviour:
FreeCAD saves the changes at original test .fcstd file location. Backup files are saved to original test .fcstd file location.
I can't find here any consensus about this.

Draft PR waiting for discussion in this thread.
- Flachy Joe -
Image
User avatar
adrianinsaval
Veteran
Posts: 5541
Joined: Thu Apr 05, 2018 5:15 pm

Re: Issues 1665 & 1666; Symbolic links & backups

Post by adrianinsaval »

There is a mention about absolute paths in your commit, does this affect the relative paths of App_Link?
flachyjoe wrote: Fri Jun 17, 2022 6:58 am Backup file is saved in link target directory as mentioned in bug report
triplus wrote:Expected behaviour:
FreeCAD saves the changes at original test .fcstd file location. Backup files are saved to original test .fcstd file location.
I can't find here any consensus about this.
for the record I agree with triplus but I'm not sure what others think, do we know some other software's behavior to compare?
Post Reply