Can't open files containing linked objects in version 3.1

[davidgiven]

• SolveSpace version: 3.1+ds1-3.1+b1
• Operating system: Linux Debian testing

If I try to open a file containing a linked object, the linked object doesn't load, and all the constraints attached to the linked object break:

Examining the loaded file, it seems that the filename for the linked object hasn't been read properly out of the slvs file:

If I run solvespace with strace, this is corroborated. I can see it load the original file, then it tries to open .:

...
read(16, "2031085529958 1.9999999999999997"..., 4096) = 4096
read(16, "t 0 -24.24264068711928388211 -4."..., 4096) = 4096
read(16, "8024742503792481330\nAddCurve\nCur"..., 4096) = 4096
read(16, "7.71427983280334217397 Weight 1."..., 4096) = 4096
read(16, "0637458226738 47.720394026388149"..., 4096) = 533
read(16, "", 4096)                      = 0
close(16)                               = 0
openat(AT_FDCWD, ".", O_RDONLY)         = 16
newfstatat(16, "", {st_mode=S_IFDIR|0775, st_size=4096, ...}, AT_EMPTY_PATH) = 0
read(16, 0x560f0e262d60, 4096)          = -1 EISDIR (Is a directory)
close(16)                               = 0
...

I noticed this with new files, i.e. the ones I'm currently working on, but trying to open some old ones which used to work also fails, so I think this is a new regression?

I'm enclosing the two files.

files.zip

[davidgiven]

Additional data: opening the file with "Open recent..." or on the command line causes the problem to manifest. However, if I open the file with "Open..." and selecting the filename manually, it seems to load fine! It seems quite repeatable.

[ruevs]

Works on Windows. Please post the result from going to Help | Go to GitHub commit. Could be related to #1465

[davidgiven]

It's https://github.com/solvespace/solvespace/commit/70bde63c, which I now realise is really old, but that's the current version in Debian.

Looking at the Debian changelog, a new version came out in 2024:

solvespace (3.1+ds1-3.1) unstable; urgency=medium

  * Non-maintainer upload.
  * Rename libraries for 64-bit time_t transition.  Closes: #1062911

 -- Benjamin Drung <[email protected]>  Thu, 29 Feb 2024 17:02:12 +0000

This seems the most plausible candidate for whatever's gone wrong, given that it worked for me before, but I don't know why this would have broken something.

[ruevs]

70bde63c is the last official release 3.1 https://github.com/solvespace/solvespace/commits/v3.1/

But this rules out my changes from last November that I mentioned in #1465 as the potential problem...

It is also VERY surprising that no one has caught this on Linux for two years?! @phkahler you are on Linux - can you reproduce this problem?

[WickedSmoke]

The feet-10deg.slvs file loads fine with 9dc81f7d + Qt changes on Fedora via "Open Recent" and CLI argument.

[WickedSmoke]

The problem also occurs on Windows in v3.1. Did you run solvespace feet-10deg.slvs @ruevs?

[davidgiven]

Oh, thank goodness --- it's not just me...

[ruevs]

I'll try from the command line and debug it tomorrow.

[ruevs]

In short - this is fixed in master - the original issue is https://github.com/solvespace/solvespace/issues/1292. The whole story:

When running (from the commend line) solvespace.exe feet-10deg.slvs with the two files (feet-10deg.slvs and m4nutcylinder.slvs) in the current directory version 3.1 fails to load the linked file. Current master loads it just fine (on Windows) because this was fixed. But there is still a small inconsistency with Linux in the path handling.

The whole history is long and complicated:

First while fixing this https://github.com/solvespace/solvespace/issues/622#issuecomment-710020308 in this commit: https://github.com/solvespace/solvespace/commit/3ea8ebfaf57ab061f18f2838f6599d10a339d59b - I removed Expand from main and at the same time I made it Expand fully in OpenFile only for Win32. Why did I not add it for Linux? I don't know - probably because it works without Expand as well - even on Windows (I just tried) - and it should be the same on Linux.

Later on I actually "fixed" the opening of assembly files with relative paths (this bug) here: https://github.com/solvespace/solvespace/commit/d5e8a8267cefe84f15541249ab886aead94c0935 related discussion: https://github.com/solvespace/solvespace/pull/1421 https://github.com/solvespace/solvespace/pull/1194 https://github.com/solvespace/solvespace/issues/1292

And finally another bug with linked files fixed here: https://github.com/solvespace/solvespace/commit/6f7e45ba9f6d25079d48f1f14564b1a0b8803c85 related discussion: https://github.com/solvespace/solvespace/issues/1347 https://github.com/solvespace/solvespace/issues/1347#issuecomment-1448979455

So finally the question remains why did I leave Linux (and anything not Windows) "behind" (without Expand) here? https://github.com/solvespace/solvespace/blob/9fb6ade06bc271ba1196b79a6ed3d1eebcea9609/src/platform/platform.cpp#L414 or why don't we remove Expand for Windows as well? Any ideas @phkahler @rpavlik @vespakoen? The cross platform path handling is rather "baroque"...

The whole history https://github.com/solvespace/solvespace/commits/master/src/platform/platform.cpp

I can make a pull request to unify the platforms - but you guys will have to test it on Linux. My Raspberry Pi is busy with other stuff :-)

The proposed "unification":

FILE *OpenFile(const Platform::Path &filename, const char *mode) {
    ssassert(filename.raw.length() == strlen(filename.raw.c_str()),
             "Unexpected null byte in middle of a path");
#if defined(WIN32)
    return _wfopen(Widen(filename.Expand(/*fromCurrentDirectory=*/true).raw).c_str(), Widen(mode).c_str());
#else
    return fopen(filename.Expand(/*fromCurrentDirectory=*/true).raw.c_str(), mode);
#endif
}

And more related stuff: https://github.com/solvespace/solvespace/issues/1465 https://github.com/solvespace/solvespace/pull/1485

[rpavlik]

I totally do not remember this, I use assemblies like all the time, though I always keep everything in the same directory. Happy to test on Linux.

[phkahler]

Is this fixed? @rpavlik have you had a chance to test it?

[ruevs]

@iscgar you are on Linux and currently actively working on SolveSpace. Would you please test/confirm that this is fixed, so that I can close it?

[iscgar]

Working fine with latest master (60d0dab0b62cd50f01981a4669233aca9f4f1806), both when running cd <solvespace-build>/bin && ./solvespace ~/files/feet-10deg.slvs as well as when running cd ~/files && <solvespace-build>/bin/solvespace feet-10deg.slvs (reading your description, it wasn't clear to me whether the problem is related to cwd handling or not, so I tested both cases just to be sure).

If there's a different scenario that needs to be tested, please specify the steps and I'd be happy to try.

[ruevs]

Thank you. What you did is enough. The relative path to the slvs file on the command line used to caue the problem, not the CWD.