Emacs - the mother of free software - creates the backup files in the target directory of the link.adrianinsaval wrote: ↑Sun Jun 19, 2022 1:08 am do we know some other software's behavior to compare?
Issues 1665 & 1666; Symbolic links & backups
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
Be nice to others! Respect the FreeCAD code of conduct!
Re: Issues 1665 & 1666; Symbolic links & backups
A Sketcher Lecture with in-depth information is available in English, auf Deutsch, en français, en español.
Re: Issues 1665 & 1666; Symbolic links & backups
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.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?
App_Link should work as expected.
All checks have passed so I'm rebasing the branch and removing the PR draft status.
Re: Issues 1665 & 1666; Symbolic links & backups
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.
Only to note that the mother of free software is not so easy to set , and many complains that FC is complicated!!!
Regards
Carlo D.
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.
If you don't change his behaviour with some obscure spells in e-lispchrisb wrote: ↑Sun Jun 19, 2022 7:57 amEmacs - the mother of free software - creates the backup files in the target directory of the link.adrianinsaval wrote: ↑Sun Jun 19, 2022 1:08 am do we know some other software's behavior to compare?
Code: Select all
(setq
make-backup-files nil
auto-save-default nil
create-lockfiles nil)
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/
- In deep articles on FreeCAD.
- Learning how to model with scripting.
- Various other stuffs.
Blog: https://okkmkblog.wordpress.com/
Re: Issues 1665 & 1666; Symbolic links & backups
@onekk I think we can fix issue #5592 now and tune the backup later as it's more a Feature Request than a Bug.
Re: Issues 1665 & 1666; Symbolic links & backups
Probably yes, my post was only a point of view that when thinking of such things IMHO should be taken in account.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.
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/
- In deep articles on FreeCAD.
- Learning how to model with scripting.
- Various other stuffs.
Blog: https://okkmkblog.wordpress.com/
- adrianinsaval
- Veteran
- Posts: 5541
- Joined: Thu Apr 05, 2018 5:15 pm
Re: Issues 1665 & 1666; Symbolic links & backups
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
Re: Issues 1665 & 1666; Symbolic links & backups
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.
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.
- adrianinsaval
- Veteran
- Posts: 5541
- Joined: Thu Apr 05, 2018 5:15 pm
Re: Issues 1665 & 1666; Symbolic links & backups
I'm confused about what is the advantage of copy+delete vs move, can you elaborate?
Re: Issues 1665 & 1666; Symbolic links & backups
Symbolic links are dereferenced with copy but not with move. Not so easy to explain with words, but hopefully this can help :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?
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
- adrianinsaval
- Veteran
- Posts: 5541
- Joined: Thu Apr 05, 2018 5:15 pm
Re: Issues 1665 & 1666; Symbolic links & backups
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
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