Assembly4: XLink absolute filepath problem

[project4]

Didn't wait for the merge, compiled the FreeCAD + realthunder changes.

It doesn't solve the problem.
In the test flow described here:
https://github.com/Zolko-123/FreeCAD_As ... /issues/95

In a directory with symbolic link to NFS drive I still get wrong path on load of the assembly with the following printounts:
08:13:03 8.1e-08 <App> Document.cpp(2844): base#channel_1120_528mm.LinkedObject: Link not restored
Linked object: Model
Linked file: channel 1120 528mm.FCStd
08:13:03 0.0004234 <App> Document.cpp(2844): base#asm_test.LinkedObject: Link not restored
Linked object: Model
Linked file: asm_test.FCStd

The linked assemblies (those that are loaded in grey) appear with wrong file name path (the absolute path to NFS mount instead of the path to logical location)

[project4]

Sorry, it does work.
Re-checked the code manually and saw that the merge with your changes didn't work well.
Fixed manually and it looks ok now. Thanks.

[project4]

May-be a solution would be to forbid a link to climb the directory hierarchy (no /../), and instead allow to define library paths (like Lib_1 = /home/user/CAD/Parts) and then link a part from that library (like Lib_1/Supplier_12/Part_1234). The library path would be set per user of course. If Part_1234 appears several times in the assembly at different levels, all links always point to the same file.

What do you think of that ?

Library paths are the basics of any code development system. Strange to hear that CAD systems don't follow that principle by default.
I don't think forbidding something is a good way to go. I can think of directory hierarchy where I would be happy to go one level up from current directory with the "..".
I do agree that using library paths is a good proposal, but it have lots of other changes that should be done.
For example, in code development platforms you specify where to look for the file, include "filename" means its a local file, include <filename> means the system should look in the library directories.
It will not be easy to implement the "look in the library directories" code...
Having one library path could be implemented with less effort.

Currently there is no way to specify that when adding a new file into assembly.
I would change the way the files are added, instead of forcing the user to have that file open, allow to select it from a directory.
The dialog could allow to select a file from local project directory, any file on PC or special predefined library directory.
When loading from library, the filename should be saved with special prefix, such as "%LIBRARY_PATH%/Lib1/FileName123".
When loading such link, the code should replace the %LIBRARY_PATH% to the predefined path.

Also, I would not allow overriding the library files, so it will not affect others who might link to the same file...

[realthunder]

I have just amended the PR. I realized that it is not that useful to add option to disable loading linked file with identical physical location. It just complicates things and limit potential valid use case. The user can later on save the file to a symlinked directory and (unknowingly) bypass the restriction. So, the right way to do it is to perform location check while saving, and warn the user.

Here is what my amendment did. When loading file, it will check for identical physical path, and print warning in report view, something like

Code: Select all

17:36:13  <App> Application.cpp(807): Identical physical path '/home/thunder/Downloads/linkpathtest.FCStd'
  with existing document 'linkpathtest' in path: '/home/thunder/DownloadsLink/linkpathtest.FCStd'

The files are still loaded as separate files. When linked file is modified and the user wants to save it, another check will be done, and warn the user with this dialog.

Screenshot from 2020-08-27 17-55-17.png (35.53 KiB) Viewed 2102 times

[Zolko]

May-be a solution would be to forbid a link to climb the directory hierarchy (no /../)

I can think of directory hierarchy where I would be happy to go one level up from current directory with the ".."

but it's incompatible with symlinks: if you go up 1 level from the linked directory, you'll end up in different locations. This might also have security implications. Therefore, a big NO for me.

I have just amended the PR.

I think you're too fast: this is a real problem, it impacts directly the user data, thus it will need to be very stable once implemented. I suggest to think this through before doing some quick fix.

In my experience, there are 3 different possible scenarios (and this is what NX proposes !):

1) absolute file path: this has actually good real-world use cases. For example, for a project by a single designer on a single computer, having absolute file-paths is no problem. Also, for a small team of designers in the same organisation, if the CAD data is in the same location on all computers (like /home/CAD/ for example), absolute paths is also a good solution. This is compatible with many projects and libraries, all that is needed is that they are all located in that CAD directory (like, CAD/Project_1, CAD/Project_2, CAD/PartsLibrary, CAD/Test ...). If you have a code repository, or need to backup the data, all that is needed is to point to that directory: it's very easy to setup and maintain, since all workstations have the same configuration. That is the reason why all high-end CAD systems (CATIA and NX at least) propose this as an option.

2) relative paths: in this case, an assembly can load parts only from within the assembly's directory. This is a good for portable projects, where you can ZIP the directory and send it around, and another user can open it from wherever it is downloaded. This is very good for self-contained projects that are shared by many people, but forbids the use of libraries.

3) Search-paths, or library paths: this is the same as 2) (files are loaded from relative paths), except that search-paths (or library-paths) can be set up additionally, so that it is possible to use common parts in the assemblies, thus it has the advantages of 1). This is the best but also the most complicated organisation to set up, because the project files and the library files can be in different directories on different workstations. But once correctly set up, this offers the best user experience.

ping

Since FreeCAD v0.19 is about to be released (hopefully one) day, it is important to have a data structure that is forward-compatible: once people begin to create projects, it would be a pity for them not to be able to re-open existing data. Therefore, since the library paths will be more difficult to implement, I'd suggest to propose options 1) (absolute paths) and 2) (relative paths without /../), with a user-settable parameter in the preferences. Then, for v0.20, library paths can be added. This is fundamentally important, please do not rush to a solution !!!

[project4]

I can think of directory hierarchy where I would be happy to go one level up from current directory with the ".."

but it's incompatible with symlinks: if you go up 1 level from the linked directory, you'll end up in different locations. This might also have security implications. Therefore, a big NO for me.

It's perfectly compatible with symlinks if logical paths will be used (as it is now with the realthunder fix).
All OS permission rules are followed. The same as you can't access other user's files from command line, unless the user explicitly gave the permissions for that.
Actually the symbolic links on Unix system let you link the library files to whatever place you want.
I can have "/home/user1/Workspace/FCproject1" directory, while the "/home/user1/Workspace" is a symbolic link to local RAID mount
and have "/home/user1/CAD_Libs/project1_lib" directory, while the "/home/user1/CAD_Libs" is a symbolic link to remote server NFS mount.
So from the project directory there will be need to link files from "../../CAD_Libs/project1_lib/" directory.
Sounds ok for me. Ofcause I would like to have it "%CAD_LIBS_PATH%/project1_lib" instead, but that's probably a long and future development.

I think you're too fast: this is a real problem, it impacts directly the user data, thus it will need to be very stable once implemented. I suggest to think this through before doing some quick fix.

I will be happy to have the fix for absolute path pushed into the main stream first.
The added warning looks reasonable enough. Taking into account that nothing of that was done before, so there is now a bonus with the warning.

1) absolute file path: this has actually good real-world use cases. For example, for a project by a single designer on a single computer, having absolute file-paths is no problem. Also, for a small team of designers in the same organisation, if the CAD data is in the same location on all computers (like /home/CAD/ for example), absolute paths is also a good solution. This is compatible with many projects and libraries, all that is needed is that they are all located in that CAD directory (like, CAD/Project_1, CAD/Project_2, CAD/PartsLibrary, CAD/Test ...). If you have a code repository, or need to backup the data, all that is needed is to point to that directory: it's very easy to setup and maintain, since all workstations have the same configuration. That is the reason why all high-end CAD systems (CATIA and NX at least) propose this as an option.

You still need the ".." supported to get from Project_1 to PartsLibrary...
That's the beauty in Linux, I can add a symlink to any place I want.
One team member could have the files in /home/CAD/Project1, another could have it in /home/Workspace/blabla/C.A.D/Project1.
The files will open fine as long as the PartsLibrary will be linked to the same level: /home/Workspace/blabla/C.A.D/PartsLibrary.

2) relative paths: in this case, an assembly can load parts only from within the assembly's directory. This is a good for portable projects, where you can ZIP the directory and send it around, and another user can open it from wherever it is downloaded. This is very good for self-contained projects that are shared by many people, but forbids the use of libraries.

Will work with the fix, even when the directory is on NFS mount, which is very common for backups and multi-PC work environment.

3) Search-paths, or library paths: this is the same as 2) (files are loaded from relative paths), except that search-paths (or library-paths) can be set up additionally, so that it is possible to use common parts in the assemblies, thus it has the advantages of 1). This is the best but also the most complicated organisation to set up, because the project files and the library files can be in different directories on different workstations. But once correctly set up, this offers the best user experience.

I actually see more similarity with absolute paths than with relative paths as you described.
The library files are not in the same directory as the project...

[aapo]

1) absolute file path: this has actually good real-world use cases. For example, for a project by a single designer on a single computer, having absolute file-paths is no problem. Also, for a small team of designers in the same organisation, if the CAD data is in the same location on all computers (like /home/CAD/ for example), absolute paths is also a good solution. This is compatible with many projects and libraries, all that is needed is that they are all located in that CAD directory (like, CAD/Project_1, CAD/Project_2, CAD/PartsLibrary, CAD/Test ...). If you have a code repository, or need to backup the data, all that is needed is to point to that directory: it's very easy to setup and maintain, since all workstations have the same configuration. That is the reason why all high-end CAD systems (CATIA and NX at least) propose this as an option.

I think absolute file paths would be feasible only if FreeCAD would be used in only one operating system, which would be quite limiting, IMHO. Windows-style "C:\CAD\" and UNIX-style "/home/CAD" paths would mix quite terribly.

2) relative paths: in this case, an assembly can load parts only from within the assembly's directory. This is a good for portable projects, where you can ZIP the directory and send it around, and another user can open it from wherever it is downloaded. This is very good for self-contained projects that are shared by many people, but forbids the use of libraries.

Why would it forbid the use of (part) libraries? You can always make a file system symbolic link inside your project dir (e.g. "myproject/part_lib_dir.lnk"), and set the link point to the part library. Then, the project files save the parts inside "myproject/part_lib_dir.lnk/whateverpart.FCStd"), and the user can make the filesystem symbolic link "part_lib_dir.lnk" to point wherever the part library is installed on the current system. Slightly more complicated, but possible, and in my experience it already works.

Thus, technically, I feel option 2 (the current option) is technically the easiest to program, most supported, and most portable solution. Granted, there could/should be automated tools to set/install the filesystem links for a project, but I believe this should be done outside the core system.

[Zolko]

I think absolute file paths would be feasible only if FreeCAD would be used in only one operating system, which would be quite limiting, IMHO.

the real-world disagrees with you.

2) relative paths: ... but forbids the use of libraries.

Why would it forbid the use of (part) libraries? You can always make a file system symbolic link inside your project dir (e.g. "myproject/part_lib_dir.lnk"), and set the link point to the part library.

because that forbids you to have multiple hierarchical levels in your assembly directory, you'd be forced to flat assemblies. You'd have to create a link to the library in each and every sub-directory (myproject/library, myproject/subasm1/library, myproject/subasm2/library, myproject/subasm1/subsubasm11/library, ...), and the files from the library would be accessed from different logical path. You would trigger this warning ALL THE BLOODY TIME !!!

Please: don't re-invent the wheel, this problem has been solved before !!! Just do it the proper way : absolute-path, relative-path, library-path.

[project4]

I think absolute file paths would be feasible only if FreeCAD would be used in only one operating system, which would be quite limiting, IMHO.

the real-world disagrees with you.

That problem is solved if you handle the current project directory as absolute path (the location where from you open the file) and the rest of the files are relative to the project directory...

[aapo]

the real-world disagrees with you.

Do you mean that FreeCAD should be intentionally made to only work in single operating system environments because some other commercial CAD systems work like that, or perhaps you meant something else? Or did you perhaps mean, that FreeCAD could somehow use Unix-style absolute paths with Windows, too? If so, I haven't been aware of this.

because that forbids you to have multiple hierarchical levels in your assembly directory, you'd be forced to flat assemblies. You'd have to create a link to the library in each and every sub-directory (myproject/library, myproject/subasm1/library, myproject/subasm2/library, myproject/subasm1/subsubasm11/library, ...), and the files from the library would be accessed from different logical path. You would trigger this warning ALL THE BLOODY TIME !!!

Granted, I mostly use flat directories for individual assemblies. It hasn't felt like a restriction so far, because I rarely include non-library parts. And, if I've understood correctly, this file access from different logical paths is something realthunder is currently trying to solve. Is it not possible to detect this situation during the file load, and only load the file once, I wonder?

Please: don't re-invent the wheel, this problem has been solved before !!! Just do it the proper way : absolute-path, relative-path, library-path.

I'm not re-inventing the wheel, just saying that realthunder's current relative-path solution already fulfills my needs quite nicely, thanks. And, I believe absolute file paths would introduce more problems than they solve.