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 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 <bdrung@debian.org>  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]

70bde63 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 9dc81f7 + 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 #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 #622 (comment) in this commit: 3ea8ebf - 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:
d5e8a82
related discussion:
#1421
#1194
#1292

And finally another bug with linked files fixed here:
6f7e45b
related discussion:
#1347
#1347 (comment)

So finally the question remains why did I leave Linux (and anything not Windows) "behind" (without Expand) here?

solvespace/src/platform/platform.cpp

Line 414 in 9fb6ade

return fopen(filename.raw.c_str(), mode);

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:
#1465
#1485