USER FORUM
(you are viewing a thread; or go back to list of threads)
Relative paths in assemblies (by Blinkenlight)
I was wondering whether SolveSpace is supposed to make any attempt to load a file (part of an assembled piece) from any sort of relative path (basically, at least from the same folder) - I'm asking because I'm working on files synced through the cloud that mount as different drive letters on different (windows) computers and even though they're all in the same folder, they're not being found / loaded.
The other reason I'm asking is because I noticed there seems to be an explicitly stored relative path along the absolute one in the files SolveSpace saves - but it doesn't seem to be used / to be working...?
The other reason I'm asking is because I noticed there seems to be an explicitly stored relative path along the absolute one in the files SolveSpace saves - but it doesn't seem to be used / to be working...?
(no subject) (by Jonathan Westhues)
If your files (assembly plus parts) are all on the same drive letter, then you should be able to move them all together while preserving the relative paths, and SolveSpace should still find them. For example, if you move
c:\alpha\part.slvs and
c:\beta\assembly.slvs
to
q:\path\alpha\part.slvs and
q:\path\beta\assembly.slvs
and load the assembly, then SolveSpace should still find the part. Let me know if it doesn't and I can take a look.
If the part and assembly are on different drive letters, then I'm not sure what heuristic could be used to find the part after it's moved. So that will generally fail, and isn't recommended.
c:\alpha\part.slvs and
c:\beta\assembly.slvs
to
q:\path\alpha\part.slvs and
q:\path\beta\assembly.slvs
and load the assembly, then SolveSpace should still find the part. Let me know if it doesn't and I can take a look.
If the part and assembly are on different drive letters, then I'm not sure what heuristic could be used to find the part after it's moved. So that will generally fail, and isn't recommended.
(no subject) (by Blinkenlight)
Okay, just checked again to be sure - the files are originally saved as something like "F:\SolveSpace\abcd.slvs". At home, I'm seeing them as drive "Z:" - but opening a file that imports another results in "Failed to load imported file F:\SolveSpace\abcd.slvs", even though I just opened the first one from "Z:\Solvespace\" and abcd.slvs is right next to it. I'd like to note though that the relative paths, aren't. This is what's in the first file:
Group.impFile=F:\SolveSpace\abcd.slvs
Group.impFileRel=F:\SolveSpace\abcd.slvs
That doesn't seem very relative...
Group.impFile=F:\SolveSpace\abcd.slvs
Group.impFileRel=F:\SolveSpace\abcd.slvs
That doesn't seem very relative...
(no subject) (by Jonathan Westhues)
I do notice that after saving the assembly for the first time, it's necessary to regenerate the model to make the filenames relative. (The program doesn't know where you'll save the assembly until you do, so it makes sense that relative import paths don't work before that; but it's not very intuitive behavior that you have to regenerate explicitly.)
Does that explain your problem?
Does that explain your problem?
(no subject) (by Blinkenlight)
Nope, it doesn't.
This stumped me for quite a while because copying the related files elsewhere was working fine. I tried everything including SUBSTing drive letters around trying to find what's so special about my cloud-mapped drive that is solely refuses to work with SolveSpace, until it finally dawned on me; the clue is here:
Group.impFile=F:\SolveSpace\Ninigi.slvs
Group.impFileRel=ninigi.slvs
The thing is, Windows probably doesn't care at all about file name case - but Dokan (through which EncFS maps in my "cloud" account) very much does. Apparently.
Changing the first letter in the relative path to uppercase to match the actual file name got it working immediately. Knowing this of course it's trivial for me to work around it but I suppose storing the name of the file verbatim, without case changes would be a good idea anyway...
This stumped me for quite a while because copying the related files elsewhere was working fine. I tried everything including SUBSTing drive letters around trying to find what's so special about my cloud-mapped drive that is solely refuses to work with SolveSpace, until it finally dawned on me; the clue is here:
Group.impFile=F:\SolveSpace\Ninigi.slvs
Group.impFileRel=ninigi.slvs
The thing is, Windows probably doesn't care at all about file name case - but Dokan (through which EncFS maps in my "cloud" account) very much does. Apparently.
Changing the first letter in the relative path to uppercase to match the actual file name got it working immediately. Knowing this of course it's trivial for me to work around it but I suppose storing the name of the file verbatim, without case changes would be a good idea anyway...
(no subject) (by Jonathan Westhues)
That'll do it; SolveSpace assumes a case-insensitive filesystem. As a workaround, files in lowercase should always behave correctly, or I just committed a fix, pushed to github and binary attached. That fix also removes the need to explicitly regenerate upon first save.
Let me know if you still see any problems.
Let me know if you still see any problems.
(no subject) (by Blinkenlight)
Awesome! Thank you very much for all your help, especially for the binary. It's working great now.
Post a reply to this comment: