[feature-request] Linux build system

[MattSturgeon]

As far as I can tell, other than VisualC++ this project is using cross platform open source libraries and should (at least theoretically) work on linux.

Is it possible to get a linux build system setup or export the project for building in qt creator?

[TanninOne]

I believe it shouldn't be a lot of work to most of this project to work with other compilers. Actually I have already fixed some of the projects to build with mingw.

However, a very central component (usvfs) is absolutely OS specific. usvfs provides the virtual file system and it's so low-level that it can't be ported, you would have to re-implemented the whole functionality.
This may actually be considerably simpler on linux than it is on windows, maybe something like https://github.com/rpodgorny/unionfs-fuse is all one would need, but there is no way I could invest the time to investigate this.

[MattSturgeon]

IIRC linux has user-space mounting built into the kernel, so you shouldn't normally need unionfs-fuse.

I don't currently have a windows box setup so can't really play too much with the code.

If modorganiser just uses usvfs for bind mounting it should (theoretically) be reasonably simple to duplicate on linux. The process specific file tree mentioned in the README sounds unfamiliar though and I'm not sure if bind mounting is possible for individual files (symlinking is) as I've only seen mount used to mount devices and directories.

[TanninOne]

Regular mounting isn't enough, we need to be able to mount multiple directories onto the same mountpoint while maintaining what's already there, with control over how filename-collisions get resolved and where newly created files get stored.

You could get fairly far with symbolic links, but unlike usvfs this requires write access to the destination directory and it doesn't allow you to reroute newly created files.

[MattSturgeon]

On UNIX symlinks do not require write access to the target (but you do need write access in the directory you create the link in, obviously). In fact they don't even require the target to exist, as they act as simple pointers.

To have a useful symlink you would want a target that exists and also read permission for the target.

You need write permission on the target to modify the target, of course, but that's fairly fundamental security and (hopefully) can only be bypassed by switching to root (technically any user with write permission).

On linux you have three options for linking the file hierarchy;

• Bind mounts (either kernel- or user-space, in memory mount points where many paths can refer to the same fs directory)
• Hard links (this is having multiple fs nodes reference the same data on disk, only works if both links are on the same fs)
• Soft/symlinks (a fs node that acts as a pointer to an arbitrary path).

Probably the most inconvenient issue of linux symlinks is knowing whether you are modifying the link itself or the target.

On your point of bind mounting individule files; this quick google result would suggest it is not a great idea on linux.

If you wanted you could create a tmp directory, mount a tmpfs filesystem on it, and do your symlinking in RAM; unmounting and removing the directory when you are done.

If on windows you are unsure of permissions because game files are in Program Files, on linux if a game is installed for a single user it is probably somewhere in their $HOME directory (e.g. $HOME/.local/share/Steam or $HOME/.minecraft). If it is installed system wide, only admin users should be allowed to modify it anyway (by switching to the root account).

[TanninOne]

That's what I meant by "destination directory".
I do know about the different link types but this doesn't change anything: usvfs maps multiple directories onto one destination, without write access to the "mountpoint" and with control over which of the origin receives newly created files. You can't do that with regular links and you can't do it with bind mounting. You may be able to do it with unionfs/aufs/overlayfs.

[MattSturgeon]

Hm, it does sound like a virtual fs would be needed... If one doesn't already exist, FUSE would be the API to look into for userspace filesystems.

I may look into it if I get a chance, but as I'm not exactly experienced and I am unfamiliar with usvfs I may not get far!

Either way, thanks for taking to time explaining what's holding this back. Also I appreciate your openness towards linux support :)