SB2 Bug using std::filesystem

Using std::filesystem operations in a program built in the SDK results in odd/incorrect file permissions.

Please see this minimal test case:
As you can see, test.out has only w permission, no r permission when copied with

std::filesystem::copy
In SDK:
    #include <filesystem>
    ​
    int main(int argc, char *argv[])
    {
    ​
        std::filesystem::path src(argv[1]);
        std::filesystem::path dst(argv[2]);
    ​
    ​
        std::error_code ec;
        std::filesystem::copy(src, dst, std::filesystem::copy_options::update_existing, ec);
    }
    [SailfishOS-4.6.0.11EA-aarch64] upstream # clang++ -std=c++17 test.cpp
    [SailfishOS-4.6.0.11EA-aarch64] upstream # ./a.out test.cpp test.out
    [SailfishOS-4.6.0.11EA-aarch64] upstream # ls -lh test.*
    -rw-r--r-- 1 1001 1001 256 Sep 19 15:43 test.cpp
    -rw-r--r-- 1 root root 256 Sep 19 15:46 test.out
    ​
    ​
    On Host:
    ​
    ╰ $ ls -lh test.*
    -rw-r--r-- 1 piggz piggz 256 Sep 19 16:43 test.cpp
    --w------- 1 piggz piggz 256 Sep 19 16:46 test.out
2 Likes

These are the syscalls made when the same program is run on my host (strace doesnt work in the sdk)

openat(AT_FDCWD, “test.cpp”, O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, “test.out”, O_WRONLY|O_CREAT|O_EXCL|O_CLOEXEC, 0200) = 4
fchmod(4, 0100644) = 0
sendfile(4, 3, [0] => [184], 184) = 184
close(4) = 0
close(3) = 0

Maybe fchmod isnt implemented correctly?

1 Like

When updating permissions using command line chmod within the sdk, permissions appear to update correctly, but on the host the remain the same. Becuase on the host there is no r permission, its not possible to cp a file within the sdk

[SailfishOS-4.6.0.11EA-aarch64] upstream # cp test.out test.2
cp: cannot open ‘test.out’ for reading: Operation not permitted
[SailfishOS-4.6.0.11EA-aarch64] upstream # ls -lh test.*
-rw-r–r-- 1 1001 1001 239 Sep 19 16:17 test.cpp
-rw----r-- 1 root root 239 Sep 19 16:24 test.out

1 Like

@vige Just tagging you as this bug report isnt in the general bug reports category :slight_smile:

Searching fchmod doesn’t yield good results on scratchbox2, maybe it is really not supported?

Tagging @martyone or @Thaodan might be more effective :slight_smile:

Usually when we talk about “the SDK” we mean the Sailfish SDK | Sailfish OS Documentation, but you probably mean the Sailfish Platform SDK | Sailfish OS Documentation, right?

As far as I understand, its a bug that goes into mb2/sb2. And that is in SFOS Platform SDK, and SFOS SDK and SFOS OBS. Or you cannot reproduce it on some of the SDKs?

Ive actually been using the regular SDK, not the platform SDK for these builds, via the sfdk tool. And as @ringus says, its in sb2/mb2 which is common to all environments

The reason I’m asking is that the bug in sb2 should be relatively¹ easy to fix. However, that is not enough to fix this on the Sailfish SDK. The Sailfish SDK works on three operating systems and two very different virtualization platforms, and in addition to that there are quite a few filesystems the host operating system might use. Getting the permissions to work in an even closely sane manner in all possible configurations is on a whole different ballpark.

¹ it’s not easy - just relatively when comparing to getting the permissions to work in all possible configurations.

2 Likes

Ok, my specific platform is Linux Host (opensuse tumbelweed), Sailfish SDK using the Virtual Box engine. Host filesystem is btrfs. Hope thats useful.

1 Like

When we get to these bugs, I do wonder whether it makes sense these days to switch over to native builds. aarch64 is available in cloud providers and, as an alternative, qemu could be used for smaller projects. I could work around permissions bugs using qemu and native builds on PC.

I tried to replicate on Linux Host (debian bookworm), with Docker build engine and ext4 filesystem. The permissions are shown correctly on host. I suspect the culprit is the VirtualBox engine, as it does not really support permissions.

What about the same issue on OBS though? on aarch 64 builds of qt6, files created by the build have invalid permissions and become uninstallable at the install section

I’m just poking around and it looked like qt6-qtbase built fine and then it started going south? Can you recall the first package that failed?

EDIT, maybe never mind. I just found your patches.

To be sure that there is a good example, we kept this just for you:

https://build.sailfishos.org/build/home:rinigus:qt6/sailfish_latest_aarch64/aarch64/kf6-kitemmodels/_log

1 Like

And I think in this case, the issue is in the execution of qmlregistrar for the creation of the .qmltypes file… which is the same in all the failing cases (except qtbase)

Hmm, links broken? unknown_package(home:rinigus:qt6/kf6-kitemmodels):

Right, I have removed it as a part of reorganizing the whole project. They are gone.

So, has anyone ever seen these kinds of failures with tools other than the Qt ones? (rcc, moc, …).

I know there’s the test case program from this thread, but with the many many things built on OBS only Qt things seem to run into major problems.

I wonder if Qt does something unusual in its tools?

1 Like