Bottles icon indicating copy to clipboard operation
Bottles copied to clipboard

[Bug]: directory mapped as a bottle drive is reset (was /mnt/d but becomes /mnt/sda)

Open igorzhilin opened this issue 2 years ago • 0 comments

Describe the bug

OS setup:

I have a multiboot PC with win10 and Debian 12 bookworm In Debian, the 2 NTFS partitions (belonging to win10) are mounted read-write as /mnt/c and /mnt/d

Bottle setup:

I have a win7 bottle Runner: sys-wine-8.0.2 In the bottle, I map /mnt/c and /mnt/d as drives I and D, respectively When I map the dirs in the bottle, their paths are replaced as follows: bottle's drive I: -> /mnt/c -> /run/user/1000/doc/d4dea084/c bottle's drive D: -> /mnt/d -> /run/user/1000/doc/18f2d105/d BEFORE: Screenshot from 2023-12-14 20-54-55

Problem:

I start the app in the bottle (foobar2000) The bottle cannot see drive D I go back to bottle settings I see that the bottle's drive D lost the mapping but the bottle's drive I remains: bottle's drive I: -> /mnt/c -> /run/user/1000/doc/d4dea084/c bottle's drive D: -> /dev/sda AFTER: Screenshot from 2023-12-14 21-03-13

Problem summary: drive mapping was /run/user/1000/doc/18f2d105/d but after bottle launch it is reset to /dev/sda

Notes:

  • the bottle's drive D used to work! I ran the app multiple times, and it could see drive D. But intermittently it was breaking and losing the mapped drive D.
  • no problem with host: /mnt/d is still mounted and fully accessible by Debian

To Reproduce

Create a bottle Runner: sys-wine-8.0.2 Compatibility > Windows version = Windows 7 Install foobar2000 in the bottle - (not sure it's the cause though) https://www.foobar2000.org/getfile/foobar2000-x64_v2.0.exe Compatibility > Manage drives = I: /mnt/c (gets replaced with /run/user/1000/doc/d4dea084/c), D: /mnt/d (gets replaced with /run/user/1000/doc/18f2d105/d) BEFORE: Screenshot from 2023-12-14 20-54-55

Start Bottle app - foobar2000 (C:\Program Files\foobar2000\foobar2000.exe) Foobar cannot see drive D Close Bottle app Check Compatibility > Manage drives = the source dir of bottle's drive C remains the same, but the source dir of drive D is now /dev/sda AFTER: Screenshot from 2023-12-14 21-03-13

How I fixed it manually as a TEMPORARY solution

Go to the bottle's dosdevices subdir (~/.var/app/com.usebottles.bottles/data/bottles/bottles/win10/dosdevices) and re-create symlink d: pointing to its original source dir (/run/user/1000/doc/18f2d105/d)

i@debian:~/.var/app/com.usebottles.bottles/data/bottles/bottles/win10/dosdevices$ ln -s /run/user/1000/doc/18f2d105/d d:
i@debian:~/.var/app/com.usebottles.bottles/data/bottles/bottles/win10/dosdevices$ ls -l
total 0
lrwxrwxrwx 1 i i 10 Dec 14 19:51 c: -> ../drive_c
lrwxrwxrwx 1 i i 10 Dec 14 22:01 com1 -> /dev/ttyS0
lrwxrwxrwx 1 i i 10 Dec 14 22:01 com2 -> /dev/ttyS1
lrwxrwxrwx 1 i i 10 Dec 14 22:01 com3 -> /dev/ttyS2
lrwxrwxrwx 1 i i 10 Dec 14 22:01 com4 -> /dev/ttyS3
lrwxrwxrwx 1 i i 29 Dec 14 22:07 d: -> /run/user/1000/doc/18f2d105/d
lrwxrwxrwx 1 i i 29 Dec 14 19:53 i: -> /run/user/1000/doc/d4dea084/c

Then the bottle sees drive D! However, only until the reboot. After the reboot, /run/user/1000 will be emptied.


Package

Flatpak from Flathub

Distribution

Debian 12 bookworm

Debugging Information

Official Package: true
Version: '51.9'
DE/WM: gnome
Display:
    X.org: true
    X.org (port): :1
    Wayland: false
Graphics:
    vendors:
        nvidia:
            vendor: nvidia
            envs:
                __NV_PRIME_RENDER_OFFLOAD: '1'
                __GLX_VENDOR_LIBRARY_NAME: nvidia
                __VK_LAYER_NV_optimus: NVIDIA_only
            icd: ''
            nvngx_path: null
    prime:
        integrated: null
        discrete: null
Kernel:
    Type: Linux
    Version: 6.1.0-15-amd64
Disk:
    Total: 33610309632
    Free: 33610153984
RAM:
    MemTotal: 62.6GiB
    MemAvailable: 55.7GiB
Bottles_envs: null

Bottles log information

21:35:04 (INFO) New drive d: added to the bottle 
21:35:15 (INFO) Launching an executable… 
21:35:15 (ERROR) Unable to load libGLX_nvidia.so.0 
21:35:15 (WARNING) Unable to locate libGLX_nvidia 
21:35:15 (INFO) Using EasyAntiCheat runtime 
21:35:15 (INFO) Using BattlEye runtime 
002c:err:wineboot:process_run_key Error running cmd L"C:\\windows\\system32\\winemenubuilder.exe -r" (126).
0024:err:ole:com_get_class_object class {1968106d-f3b5-44cf-890e-116fcb9ecef1} not registered
0024:err:ole:com_get_class_object class {1968106d-f3b5-44cf-890e-116fcb9ecef1} not registered
0024:err:ole:create_server class {1968106d-f3b5-44cf-890e-116fcb9ecef1} not registered
0024:err:ole:com_get_class_object no class object {1968106d-f3b5-44cf-890e-116fcb9ecef1} could be created for context 0x17

Troubleshooting Logs

No response

Additional context

No response

igorzhilin avatar Dec 14 '23 20:12 igorzhilin