I take my shitposts very seriously.

  • 2 Posts
  • 430 Comments
Joined 1 year ago
cake
Cake day: June 24th, 2023

help-circle
  • I’ve done my tests, and it looks like I may have been incorrect.

    Point 1. While I was right to suspect the : character, I discovered that it is permitted in NTFS and only reserved in Windows. When an NTFS volume is mounted in Linux, it only becomes a problem if the windows_names option is used. Sometimes it is used, sometimes it isn’t, and I don’t know when.

    Point 2. The other thing I found is that Wine only works if the wineprefix is owned by the user. NTFS doesn’t understand Unix-style file ownership and permissions, so it must determine the uid, gid, and umask when the volume is mounted. When mounted with OP’s fstab entry, it will default to root, so every file (including the wineprefixes) within the volume will appear as being owned by root, which prevents Wine from starting.

    This might also explain why mounting the drive dynamically worked, as it probably used udisks2 to mount it as the user.

    The solution may be as simple as specifying the uid and gid mount options. In a system with a single user, they should both be 1000, but you can check them by running echo $UID $GID.

    The modified fstab entry should be:

    UUID=E01A2CEC1A2CC180 /mnt/games ntfs nofail,uid=1000,gid=1000 0 3
    

    This will present all files as being owned by the user, and should allow wine to run.

    Point 3. That being said, mixing Windows and Linux is still not a good idea. I don’t know what will happen if you create wineprefixes on NTFS. Windows might see the invalid filenames and shit itself. I tried doing it on a new NTFS volume and Windows wouldn’t even mount it.

    If you really want to keep the game files on the NTFS volume, you might have better luck trying your own symlink fuckery. If you have the Steam library on the NTFS device, you could try moving the .../SteamLibrary/steamapps/compatdata directory to a Linux filesystem, then creating a symlink in compatdata’s place that points to the moved directory. This method moves the problematic files outside the volume.

    The second method involves bringing the game files on the NTFS volume into the default Steam library on the Linux filesystem using a bind mount – a way to mount a directory at a different mount point. In essence, this replaces the .../steamapps/common directory with that on the NTFS volume, and avoids creating wineprefixes inside the NTFS filesystem in the first place.

    • Mount the NTFS volume using the fstab entry above.
    • Assuming that you have the Steam stuff in their default locations, execute sudo mount --bind /mnt/games/SteamLibrary/steamapps/common ~/.local/share/Steam/steamapps/common to create the bind mount manually.
    • Or use the equivalent fstab entry:
    /mnt/games/SteamLibrary/steamapps/common /home/salty/.local/share/Steam/steamapps/common none defaults,bind 0 0
    


  • Not really, because some files in the wineprefix will have invalid names.

    When an NTFS volume is mounted, it implicitly uses the windows_names option, which restricts the character set that can be used in filenames, in order to preserve compatibility with Windows. The specific character in question is the colon – it is permitted by NTFS, but it’s a reserved character in Windows, which means it is also restricted by the windows_names mount option. This prevents Wine from creating its c: and z: symlinks, which are required for Wine to operate.

    You could try some symlink fuckery, like linking .../steamapps/common to the NTFS drive, since all of the problematic files are located outside of that, in .../steamapps/compatdata. Or you could mount the NTFS volume directly to the common directory. If you do, I’d love to hear the results.

    Relevant issue: https://github.com/storaged-project/udisks/issues/713



  • Promises from a for-profit company don’t mean shit. How many times have you seen the “we’ve heard you and we’ll do better next time” routine, only for next time to be the same or worse? They’d promise you the pissing Sun if it meant more dollar signs.

    They’re empty words. No company will put out a statement saying “we fucked up, we’re sorry, it’s going to happen again”. Until Mozilla can prove through actions that the issue is fixed, Hill is correct in distrusting them.



  • They’re definitely both used. When a program is started in a Wine environment, those symlinks are the only way it can access the filesystem: game files in .../steamapps/common through z:; settings and saved games (normally in the Windows user’s home directory) through c:.

    You can run wine explorer.exe to open a Windows Explorer implementation and check out what the Linux filesystem looks like in Windows. You can even add new lettered drives using winecfg, although I wouldn’t try it with Steam’s prefixes.


  • I don’t know for sure, but I have an idea.

    By default, Steam creates wineprefixes in ~/.steam/steam/steamapps/compatdata/GAME_ID. This is located in the user home, which should be a Linux filesystem (ext4, btrfs, and similar). If the drive is mounted statically through fstab, the prefixes are created on the mounted drive. If the drive is mounted dynamically, Steam might think it’s a USB stick, likely with a FAT32 filesystem, and preemptively create the prefixes inside the user home to ensure compatibility.

    I’ll have to do some testing once I get home.


  • UPDATE: This can be a possible solution, but might not be what OP needs.

    Wineprefixes don’t work right on NTFS filesystems because some files contain colons, which is a reserved character in NTFS and FAT.

    If you look inside the game’s wineprefix, the dosdevices directory will typically have two symbolic links: one named c: that points to the drive_c directory, and another named z: that points to the filesystem root (plus a few others that are irrelevant). These will appear as lettered drives for programs running inside Wine. If the wineprefix is on an NTFS partition, those files can’t be created because their names contain an invalid character.

    You’ll have to either relocate the wineprefixes to an ext4 or btrfs partition (I don’t know if you can do that on Steam), or format the NTFS drive using ext4 or btrfs.

    when I mount the drive through steam, I get a Polkit password prompt

    It’s not related to the issue, mounting a device usually requires elevated privileges. The same thing happens when it is mounted through fstab, except the process that mounts it already has elevated privileges. Access to the filesystem is not affected by this.




  • The relevant part in simple terms: if an app is distributed on the App Store, all in-app purchases must be made through the App Store (so Apple can have their 30%), the app can’t bypass this, and the app can’t contain links/buttons/calls to action to have the user bypass it. Epic implemented their own independent in-app purchase solution that violated this, and they got kicked out.

    Whether or not the 30% cut is fair is not relevant to the topic. I think it’s a baseless amount, and Apple’s walled garden is clearly anti-competitive and anti-consumer. The point is that Epic’s violation of the TOS was a premeditated action in order to inject their fake “for the players” narrative into their litigations and rally the Fortnite-addicted kids who didn’t know better. They had an 80-page lawsuit and a pissing CGI short film ready on the day. Apple wants all of the money, Epic wants all of the money, and they’re not above using every dirty trick they know.

    Obligatory IANAL, and this is old info, TOS may have changed. Hoeg Law on Youtube specializes in video games, it probably has a more in-depth and up-to-date analysis of the situation.





  • At this point, the distinction between console and PC comes down to the corporate side. The PS4 and PS5 operating systems are based on a BSD (probably FreeBSD but not sure), and are capable of running a desktop OS (as long as hackers find a way to bypass Sony’s locked-down firmware). XBox One and Series use a Windows-based OS, also locked down by Microsoft to only run the applications they want.

    Everything about the Steam Deck is designed with gaming in mind, but in terms of capabilities, it’s no different from a PC. You could hook it up to a USB-C dock and use it for work. I’d sooner call it a handheld PC than a console.