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!
chrisb
Veteran
Posts: 53945
Joined: Tue Mar 17, 2015 9:14 am

Re: Issues 1665 & 1666; Symbolic links & backups

Post by chrisb »

adrianinsaval wrote: Sun Jun 19, 2022 1:08 am do we know some other software's behavior to compare?
Emacs - the mother of free software - creates the backup files in the target directory of the link.
A Sketcher Lecture with in-depth information is available in English, auf Deutsch, en français, en español.
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 »

adrianinsaval wrote: Sun Jun 19, 2022 1:08 am There is a mention about absolute paths in your commit, does this affect the relative paths of App_Link?
The opened file name is not changed and the path resolution only occurs after the document content is fixed so the path stored in the document is still the same.
App_Link should work as expected.

All checks have passed so I'm rebasing the branch and removing the PR draft status.
- Flachy Joe -
Image
User avatar
onekk
Veteran
Posts: 6149
Joined: Sat Jan 17, 2015 7:48 am
Contact:

Re: Issues 1665 & 1666; Symbolic links & backups

Post by onekk »

Edit:
Out of the joke, probably some settings to tune this behaviour will be useful, as due to the size of some FC files, it could be handy to have some settings maybe in Preferences to choose maybe an unified "backup directory" or similar behaviour.

chrisb wrote: Sun Jun 19, 2022 7:57 am
adrianinsaval wrote: Sun Jun 19, 2022 1:08 am do we know some other software's behavior to compare?
Emacs - the mother of free software - creates the backup files in the target directory of the link.
If you don't change his behaviour with some obscure spells in e-lisp :lol:

Code: Select all

(setq
 make-backup-files nil
 auto-save-default nil
 create-lockfiles nil)
Only to note that the mother of free software is not so easy to set :-D, and many complains that FC is complicated!!!

Regards

Carlo D.
GitHub page: https://github.com/onekk/freecad-doc.
- In deep articles on FreeCAD.
- Learning how to model with scripting.
- Various other stuffs.

Blog: https://okkmkblog.wordpress.com/
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 »

@onekk I think we can fix issue #5592 now and tune the backup later as it's more a Feature Request than a Bug.
- Flachy Joe -
Image
User avatar
onekk
Veteran
Posts: 6149
Joined: Sat Jan 17, 2015 7:48 am
Contact:

Re: Issues 1665 & 1666; Symbolic links & backups

Post by onekk »

flachyjoe wrote: Sun Jun 19, 2022 11:28 am @onekk I think we can fix issue #5592 now and tune the backup later as it's more a Feature Request than a Bug.
Probably yes, my post was only a point of view that when thinking of such things IMHO should be taken in account.

Regards.

Carlo D.
GitHub page: https://github.com/onekk/freecad-doc.
- In deep articles on FreeCAD.
- Learning how to model with scripting.
- Various other stuffs.

Blog: https://okkmkblog.wordpress.com/
User avatar
adrianinsaval
Veteran
Posts: 5541
Joined: Thu Apr 05, 2018 5:15 pm

Re: Issues 1665 & 1666; Symbolic links & backups

Post by adrianinsaval »

fine by me and thinking it through a little more backups in the target directory are probably better since it will be easier to replace the file with a backup, if the backup is in the link directory you'll have to first go to the target anyways to replace unless you want to lose the link
openBrain
Veteran
Posts: 9034
Joined: Fri Nov 09, 2018 5:38 pm
Contact:

Re: Issues 1665 & 1666; Symbolic links & backups

Post by openBrain »

IMO, symbolic links are just one aspect of a more larger problem in FC saving strategy.
Another example is respecting the "read-only" parameter of the file. ;)

A bit more explanation.
For example if we have a document named "doc.FCStd", what happens when we save it again is :
* Create the new document as a temporary doc
* Rename "doc.FCStd" as "doc.FCStd1" (all that may vary depending on your backup policy, but not important here)
* Rename the temporary doc as "doc.FCStd"

What would IMO properly solves all kind of issues is to change this to :
* Create the new document as a temporary doc
* Copy "doc.FCStd" as "doc.FCStd1" (have to manage all backups, not important again)
* Copy temporary doc as "doc.FCStd"
* Delete temporary doc
This would of course increase a bit time needed to save file but should be reasonable.
User avatar
adrianinsaval
Veteran
Posts: 5541
Joined: Thu Apr 05, 2018 5:15 pm

Re: Issues 1665 & 1666; Symbolic links & backups

Post by adrianinsaval »

I'm confused about what is the advantage of copy+delete vs move, can you elaborate?
openBrain
Veteran
Posts: 9034
Joined: Fri Nov 09, 2018 5:38 pm
Contact:

Re: Issues 1665 & 1666; Symbolic links & backups

Post by openBrain »

adrianinsaval wrote: Tue Jun 21, 2022 1:25 pm I'm confused about what is the advantage of copy+delete vs move, can you elaborate?
Symbolic links are dereferenced with copy but not with move. Not so easy to explain with words, but hopefully this can help :

Code: Select all

### Symbolic link dereferencing in read mode
OB@OB-PC:/tmp$ echo "TEST" > test # create a basic file
OB@OB-PC:/tmp$ ln -s test testlnk # create a symbolic link to file
OB@OB-PC:/tmp$ ls -l test*
-rw-rw-r-- 1 OB OB 5 juin  21 15:55 test
lrwxrwxrwx 1 OB OB 4 juin  21 15:56 testlnk -> test
OB@OB-PC:/tmp$ cp testlnk testcp
OB@OB-PC:/tmp$ ls -l test*
-rw-rw-r-- 1 OB OB 5 juin  21 15:55 test
-rw-rw-r-- 1 OB OB 5 juin  21 15:57 testcp
lrwxrwxrwx 1 OB OB 4 juin  21 15:56 testlnk -> test
### We see here that testlnk has been dereferenced with cp function
### testlnk still exists unchanged and testcp is actually a new file being a copy of test
OB@OB-PC:/tmp$ mv testlnk testmv
OB@OB-PC:/tmp$ ls -l test*
-rw-rw-r-- 1 OB OB 5 juin  21 15:55 test
-rw-rw-r-- 1 OB OB 5 juin  21 15:57 testcp
lrwxrwxrwx 1 OB OB 4 juin  21 15:56 testmv -> test
### We see here that testlnk has NOT ben dereferenced with mv function
### So testlnk doesn't exist anymore and has been renamed testmv


### Symbolic line dereferencing in write mode
OB@OB-PC:/tmp$ echo "TEST" > test # create a basic file
OB@OB-PC:/tmp$ ln -s test testlnk # create a symbolic link to file
OB@OB-PC:/tmp$ echo "TEST_NEW" > test_new # another file
OB@OB-PC:/tmp$ cp test_new testlnk 
OB@OB-PC:/tmp$ ls -l test*
-rw-rw-r-- 1 OB OB 9 juin  21 16:00 test
lrwxrwxrwx 1 OB OB 4 juin  21 15:59 testlnk -> test
-rw-rw-r-- 1 OB OB 9 juin  21 16:00 test_new
OB@OB-PC:/tmp$ cat test
TEST_NEW
### We see here that testlnk has been dereferenced with cp function
### testlnk still exists unchanged and test content is now a copy of test_new
OB@OB-PC:/tmp$ mv test_new testlnk
OB@OB-PC:/tmp$ ls -l test*
-rw-rw-r-- 1 OB OB 9 juin  21 16:00 test
-rw-rw-r-- 1 OB OB 9 juin  21 16:00 testlnk
### We see here that testlnk has NOT been dereferenced with mv function
### testlnk no more exists as it was and is now a file
User avatar
adrianinsaval
Veteran
Posts: 5541
Joined: Thu Apr 05, 2018 5:15 pm

Re: Issues 1665 & 1666; Symbolic links & backups

Post by adrianinsaval »

got it, but is that default behavior of c++ functions or something implemented by coreutils?

And what about a link to a link? is that handled by your code @flachyjoe ? I tried in bash an it is handled by cp
Post Reply