Reconsider the "Browse C:\ Drive" launcher

Bug #223989 reported by André Pirard
38
This bug affects 4 people
Affects Status Importance Assigned to Milestone
Nautilus
Won't Fix
Low
nautilus (Ubuntu)
Won't Fix
Low
Ubuntu Desktop Bugs
wine1.4 (Ubuntu)
Won't Fix
Medium
Scott Ritchie
wine1.6 (Ubuntu)
Triaged
Medium
Scott Ritchie

Bug Description

Nautilus (and KDE/XFCE equivalent) needs a default bookmark to ~/.wine/dosdevices/c: so that browsing the Wine C:\ drive can be done from the Places menu rather than the Application menu. This icon is hidden if this folder doesn't exist, so it should only affect users with Wine installed and configured.

---original report---
An easy one :-)
The launcher named "Browse C:\ Drive" executes the command
xdg-open ~/.wine/drive_c
The command should be
xdg-open ~/.wine/dosdevices/c:
(correctly displaying the c: directory wherever it is)
Cheers, André.

Tags: patch

Related branches

Revision history for this message
Scott Ritchie (scottritchie) wrote :

Sure. It's an easy change, although winecfg won't let you remap your C:\ drive these days for very good reasons.

Changed in wine:
assignee: nobody → scottritchie
importance: Undecided → Low
status: New → Confirmed
Revision history for this message
Robert (robrwo) wrote :

I get complaints about the tilde "~" that the systtem does not know how to handle the protocol "~/.wine/drive_c". (I can run xdg-open ~/.wine/dosdevices/c: from a Bash terminal window, though.)

I think it might be that I am using Xfce with Thunar file manager.

So I've changed the line in /usr/share/applications/wine-browsedrive.desktop to Exec=xdg-open $HOME/.wine/dosdevices/c:

Revision history for this message
André Pirard (a.pirard) wrote : Re: [Bug 223989] Re: wine: incorrect "Browse C:\ Drive" launcher

> Sure. It's an easy change, although winecfg won't let you remap your
> C:\ drive these days for very good reasons.
>
Ah. What are those good reasons? Let's speak about the reason for
remapping C:\

Imagine installing Ubuntu for 10 kids, all having their profiles, and
their 50 Windows programs. That's 500 installations.

What I, many people, and Wine HQ themselves under 3.2.4 of
http://www.winehq.org/site/docs/wineusr-guide/using-regedit#AEN361
are trying to do is saving disk space & time by minimizing installations.
They want to share, and hence to relocate the C:\ drive.
That's also proving that Linux is at least as good a multiuser system as
Windows :-)

Its a matter of structuring Wine's directories to mimic Windows'.

Windows (XP/NT) directories are structured as follows (as seen by
non-adm users):
- WINDOWS and PROGRAM FILES are global & read-only
- user space and TEMP are local and read-write

I and they are surprised Wine doesn't do that.
Is there really no doc about setting up multiuser Wine on WineHQ?
That would spare many users much time.

What I have done is globalise and change permissions of drive_c.
I just realized that I'd better globalise dosdevices as well and
disallow changes to it.
system.reg is globalised, user.reg stays local.
What is userdef.reg and what to do with it?

My biggest problem is with launchers in the Applications menu.
A Wine installation makes them local. How can I make them global?

Things would be easier too if files attributes were inherited like in
Windows.

Revision history for this message
Scott Ritchie (scottritchie) wrote : Re: wine: incorrect "Browse C:\ Drive" launcher

The good reason is that too many users were remapping their C:\ drive to an actual Windows C:\ drive, breaking both it and Wine.

Revision history for this message
Scott Ritchie (scottritchie) wrote :

Fixed in Intrepid (I'm not sure why this bug wasn't automatically closed when I uploaded it).

Changed in wine:
status: Confirmed → Fix Released
Revision history for this message
Robert Hrovat (robi-hipnos) wrote :

It doesn't seem to be fixed. The menu entry still does not open Browse C: Drive

Revision history for this message
Scott Ritchie (scottritchie) wrote :

I'm reopening this bug. Something changed in Intrepid (perhaps recently) that broke this again in Wine. I have a fix that I think will work though: for some reason running xdg-open .wine/dosdevices/c\: works but if you include the $HOME you get "
Error showing url: Error stating file '/home/cmonopoly72/$HOME/.wine/dosdevices/c:': No such file or directory" in .xsession-errors.

See this thread: http://ubuntuforums.org/showthread.php?p=6037975#post6037975

Changed in wine:
importance: Low → Medium
status: Fix Released → In Progress
milestone: none → ubuntu-8.10
Changed in wine:
status: In Progress → Fix Committed
Revision history for this message
Scott Kitterman (kitterman) wrote :

Ack'ed on IRC already for motu-release

Revision history for this message
Scott Ritchie (scottritchie) wrote :

Requesting Ack from MOTU-release. Sorry for doing things out of order, but the upload is currently waiting approval. Thanks!

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package wine - 1.0.1-0ubuntu2

---------------
wine (1.0.1-0ubuntu2) intrepid; urgency=low

  * debian/wine-browsedrive.desktop:
    - remove $HOME in Exec=xdg-open .wine/dosdevices/c:
    - Should make "Brose C:\ Drive" work again. (LP: #223989)
  * debian/control:
    - Replace libcupsys2-dev build depend with renamed libcups2-dev

 -- Scott Ritchie <email address hidden> Sun, 26 Oct 2008 12:06:10 -0700

Changed in wine:
status: Fix Committed → Fix Released
Revision history for this message
André Pirard (a.pirard) wrote :

Yep, thank you. Intrepid's Wine 1.0.1 uses ~/.wine/dosdevices/c: indeed.
But upgrading an existing Wine to 1.1.17 uses ~/.wine/drive_c again.

http://ubuntuforums.org/showthread.php?p=6037975#post6037975
is not about drive_c vs dosdevices/c:
but about using $HOME

Hence, problem is not solved.

Revision history for this message
Johan Larsson (seven-naugas) wrote :

I just upgraded to 9.04/Wine 1.1.22 from 8.04, and this "Browse C:\ Drive" shortcut stopped working. Removing the tilde and following slash in the original command for the shortcut - "xdg-open ~/.wine/drive_c" - made it work again. Executing that command in the terminal brings up the folder correctly however, which I find strange - why is there a difference?

Revision history for this message
André Pirard (a.pirard) wrote : Re: [Bug 223989] Re: wine: incorrect "Browse C:\ Drive" launcher

On 2009-06-05 16:58, Johan Larsson wrote :
> I just upgraded to 9.04/Wine 1.1.22 from 8.04, and this "Browse C:\
> Drive" shortcut stopped working. Removing the tilde and following slash
> in the original command for the shortcut - "xdg-open ~/.wine/drive_c" -
> made it work again. Executing that command in the terminal brings up the
> folder correctly however, which I find strange - why is there a
> difference?
>
While executing the command from the command line or a script, the
shell (bash) expands the character ~ to the value in $HOME. As I
understand it, executing it from a launcher (.desktop) is not supposed
to do that but it did up to 8.04. Making the command sh -c "xdg-open
~.." would.
Note that, according to Wine HQ, that launcher feature is "Ubuntu's doing".
But I can't figure how then it is not removed when upgrading to a
release downloaded from HQ.

Revision history for this message
skierpage (skierpage) wrote : Re: wine: incorrect "Browse C:\ Drive" launcher

Please reopen this bug, the fix breaks Kubuntu 9.04 as reported in Ubuntu question #70652.

The fix in comment #10
 - remove $HOME in Exec=xdg-open .wine/dosdevices/c:
leads Kubuntu to fail with
 The file or folder file:///home/<MyUserName>/Documents/.wine/dosdevices/c: does not exist.

The behavior of xdg-open given a relative path is unspecified. Kubuntu winds up opening KUrl("file:///home/<MyUserName>/Documents/.wine/dosdevices/c:") -- note "Documents" in the path -- and thus fails.

Reverting /usr/share/applications/wine-browsedrive.desktop to
 Exec=xdg-open $HOME/.wine/dosdevices/c:
fixes Kubuntu. That feels like the right fix to me but it sounds as if it will once again break Gnome desktops.

The Portland project XDG spec at freedesktop.org don't say what shell expansions should work or what the final path should be for a relative path in Exec=xdg-open; the XDG spec has to specify one or the other in order to determine the right fix for this bug.

Revision history for this message
Scott Ritchie (scottritchie) wrote :

The real solution to this is to get rid of the Browse C:\ Drive launcher entirely and replace it with a bookmark in Gnome (if the directory doesn't exist then Gnome will hide it automatically). Can a similar thing be done in XFCE and KDE?

Changed in wine (Ubuntu):
status: Fix Released → Triaged
description: updated
Changed in nautilus:
status: Unknown → New
Changed in nautilus (Ubuntu):
status: New → Triaged
importance: Undecided → Low
assignee: nobody → Ubuntu Desktop Bugs (desktop-bugs)
importance: Low → Undecided
status: Triaged → New
Changed in nautilus (Ubuntu):
importance: Undecided → Low
status: New → Triaged
Changed in nautilus:
status: New → Won't Fix
Changed in nautilus:
importance: Unknown → Low
Revision history for this message
Scott Ritchie (scottritchie) wrote :

Nautilus doesn't want to do it, and I think we'll have to live with the existing launcher for a while. Making it discoverable in Unity is an interesting question.

Changed in nautilus (Ubuntu):
status: Triaged → Won't Fix
summary: - wine: incorrect "Browse C:\ Drive" launcher
+ Reconsider the "Browse C:\ Drive" launcher
affects: wine (Ubuntu) → wine1.4 (Ubuntu)
Changed in wine1.4 (Ubuntu):
milestone: ubuntu-8.10 → none
Changed in wine1.6 (Ubuntu):
status: New → Triaged
importance: Undecided → Medium
Changed in wine1.4 (Ubuntu):
status: Triaged → Won't Fix
Changed in wine1.6 (Ubuntu):
assignee: nobody → Scott Ritchie (scottritchie)
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.