[Bug 52369] New: "Brother's Keeper" can't access mounted file systems
https://bugs.winehq.org/show_bug.cgi?id=52369 Bug ID: 52369 Summary: "Brother's Keeper" can't access mounted file systems Product: Wine Version: 6.0.1 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: minor Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: jervin(a)cfl.rr.com Distribution: --- Created attachment 71559 --> https://bugs.winehq.org/attachment.cgi?id=71559 winecfg drives setup In the program "Brother's Keeper",spanning multiple wine versions, the program can't access data on mounted file systems unless the winecfg drive only points to the mount point, rather than a lower folder/directory in the mounted file system. For instance. If the data file I want to access is on my remote drive as directory BK7. So, if I use mount point /mnt/A meaning my data is at /mnt/A/BK7. If I specify in winecfg drive that K: is /mnt/A/BK7, it won't work. In the program, which I list the available files, instead of K, in lists -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=52369 --- Comment #1 from John Ervin <jervin(a)cfl.rr.com> --- Created attachment 71560 --> https://bugs.winehq.org/attachment.cgi?id=71560 Inside BK7 error -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=52369 --- Comment #2 from John Ervin <jervin(a)cfl.rr.com> --- In my case, I mount it on /mnt/ddrive as /mnt/ddrive/bk7. This doesn't work. I could point winecfg at /mnt and it will work, but specifying /mnt/DDrive or /mnt/DDrive/BK7 do not work. This also happens in the current version of Crossover btw. It's an annoyance and makes it more difficult to run the program on multiple virtual and real machines because you have to make sure that you always specify k:/DDrive/BK7 for every file rather than k: and if you change that slightly between machines, you have to go do a global update to change the file paths. But it is circumventable by being careful. Brother's Keeper is a VB6 application, so it might be related to that. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=52369 Leon <leon.dejong(a)hotmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |leon.dejong(a)hotmail.com --- Comment #3 from Leon <leon.dejong(a)hotmail.com> --- (In reply to John Ervin from comment #0)
Created attachment 71559 [details] winecfg drives setup
In the program "Brother's Keeper",spanning multiple wine versions, the program can't access data on mounted file systems unless the winecfg drive only points to the mount point, rather than a lower folder/directory in the mounted file system. For instance. If the data file I want to access is on my remote drive as directory BK7. So, if I use mount point /mnt/A meaning my data is at /mnt/A/BK7. If I specify in winecfg drive that K: is /mnt/A/BK7, it won't work. In the program, which I list the available files, instead of K, in lists
I cannot reproduce this. I have an external disk that holds the data which is called PORTABLE_B and on it a (sub)folder called "Brother's Keeper". My DATA folder is under this one. - Linux mounts the disk as /media/leon/PORTABLE_B. - Windows sees it as D:\ Within winecfg I can add a drive D: pointing to /media/leon/PORTABLE_B/. In Brother's Keeper (7.5.9) I can now browse to D: and select the DATA folder from under Brother's Keeper, just as in Windows so my path references inside the database point all to the same location (D:\BROTHER'S KEEPER\DATA). I've tested it even by moving the installation to a sub-sub folder (BK/Brother's Keeper) and still could point all instances to the same folder with D: pointing to /media/leon/PORTABLE_B/BK. I can move the disk (1TB USB exFAT) between Windows XP or Windows 7 and Linux Mint 20.2 'Uma' or Linux Mint 20.3 'Una' without issues. Questions: - is your K: also mountable from /media (as /media/jervin/DDrive)? - in your BK screenshot you select drive Z, not drive K? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=52369 --- Comment #4 from John Ervin <jervin(a)cfl.rr.com> --- Let me be more specific. The file system is on a remotely connected NAS device that is nfs mounted (/etc/fstab). I think it also happens with remotely mounted cifs file systems too. This is all on my home LAN. Like I said, I can make it work, but not the way I want. I think it works with locally mounted file systems, such as USB drives and external hard drives. Mounting this way seems to work for other programs, such as Quicken. If you have two computers on a LAN, try using SMB/cifs to mount a file system from another computer. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=52369 --- Comment #5 from Leon <leon.dejong(a)hotmail.com> --- Ok, that makes sense. Couldn't read that from your first report so assumed things. I've been able to set up a similar situation: drop a Samba server in the network and share a folder, then mount over SMB. That all works as expected and I have a local mount at /media/bktest. Within winecfg I can map D: to any folder on the mount but it results in the same issues (drive not available, error=76) when trying to use it in BK. So... I've been able to reproduce the error. I'll now dig deeper into the system to see where it's going wrong. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=52369 --- Comment #6 from John Ervin <jervin(a)cfl.rr.com> --- You have greater debugging skills than I do. I think it's a visual basic application. And I did get with the author to figure out the workaround that got it working on wine, but that's about the limit for me. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=52369 --- Comment #7 from Leon <leon.dejong(a)hotmail.com> --- Created attachment 71609 --> https://bugs.winehq.org/attachment.cgi?id=71609 BK's dialog -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=52369 --- Comment #8 from Leon <leon.dejong(a)hotmail.com> --- Created attachment 71610 --> https://bugs.winehq.org/attachment.cgi?id=71610 Windows Default Dialog -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=52369 --- Comment #9 from Leon <leon.dejong(a)hotmail.com> --- OK, progress! I checked the mounting and mapping and came to the conclusion that that's not the culprit. When you open an explorer (from winetricks) you get a perfect mapping (D: in my case) and can operate on all the files visible. This made me believe it's not Wine that's the issue. You would have had many more complaints from other users as well. So then I moved on to BK. I checked if it uses any external controls for network/dialog functionality and it doesn't. There are only a few external libraries for BTrieve (the database side of the app). I went into the archives of memory lane and dusted off my VB disks and made a q&d mock up of the screen that John Steed made. And the default Drive control does the same: it shows my mapped D: drive as ] and gave me an error 76 (drive not available). https://bugs.winehq.org/attachment.cgi?id=71609 To check whether it's really the control, I created an option with the default Windows dialog to browse for the folder. This dialog shows the correct mapping and path so the conclusion is that it's the Drive control of VB6 that doesn't pick up the network mapping. https://bugs.winehq.org/attachment.cgi?id=71610 I'm now trying to create a function that shows the result of the default dialog under the Drive control so John Steed only needs to update the code behind the Drive control (if he'd be willing to address this issue). So stay tuned ... :-) -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=52369 --- Comment #10 from Leon <leon.dejong(a)hotmail.com> --- Created attachment 71612 --> https://bugs.winehq.org/attachment.cgi?id=71612 Fixed dialog -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=52369 --- Comment #11 from Leon <leon.dejong(a)hotmail.com> --- https://bugs.winehq.org/attachment.cgi?id=71612 Well, that was easy. A quick fix that doesn't show fancy images but this is with out-of-the-box VB. Can always spruce things up if required :-) I'll contact John and see what we can do. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=52369 --- Comment #12 from John Ervin <jervin(a)cfl.rr.com> --- I thank you for your work to resolve this. I have found that John Steed is pretty easy to work with. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (1)
-
WineHQ Bugzilla