The Problem

the problematic case: the diagnosis case:

The Diagnosis

See files/drive.c DRIVE_Init - the drive-letters from .wine/config are scanned and checked with stat(2) whether they do exist. When a stat fails, then simply say

   MESSAGE("Could not stat %s (%s), ignoring drive %c:\n" 
and remove the drive from the list of drives, permanently.

The autofs (bsd automounter) has an empty "/vol" master mount-point by default. As soon as an access is made to a mounted device then the device-specific mount-point is created. Accessing "/vol/a" makes the mount-point to appear and the device fd0 to be mounted. As soon as the device is auto-unmounted, the device's mount-point will be removed as well. When no medium is inserted, then the mount-point will never come into existance - it is "not accessible" instead of "empty".

When a medium had been inserted before starting up `wine` and removing the medium later, then wine will print a warning message when the file-open dialog-box opens, but wine will continue to function properly. Inserting a medium just then will allow to access files on the medium (just like we expect from drive "A:"). wine-vol-a-nomedium.png

The Reason

The reason for these symptoms is the decoupling of processing of inaccessible drives. The DRIVE_Init will happily remove any drive from the drivelist when it was inaccessible at first start of wine, and it will never recheck later when the mount-point comes into existance - either trough the functionality of an autofs bsd automounter or manual admin intervention in the filesystem. The wine has to be relaunched to make the drive to appear.

This remove is not actually needed since the drive-access routines can handle non-existent mount-points - they recover and just like in windows, the drive is called "inaccessible" which is both correct for "removable media drives" and "network shares".

In most realworld cases, the non-existance of a mount-point is a symptom of a misconfiguration of wine. This is due to the nature of manually edited .wine/config files instead of using a setup-wizard that would check-and-warn the mount-points that are to be used. Still, there are cases where it is even correct that the mount-point does not exist: with a bsd automounter.

The Patch

We present a patch that does not change the current standard functionality of wine, instead we introduce a new .wine/config boolean option "AutoMount" that can be put into the drive-section. Setting this option will make the DRIVE_Init routine to accept non-existant mount-points as simply being non-existant: they are still kept in the wine's drivelist.

The alternate execution path via "AutoMount = 1" does also print a warning message but it does explicitly say now

  MESSAGE("Could not stat %s (%s), keeping automount drive %c:\n" 
and does continue in initial drivelist handling - which inserts the drive into the internal drivelist finally instead of throwing it away. Later access prints warning messages from later routines which are not a problem in this case. (inserted pic for /vol/m).

This patch has been successfully used in the last two months without any problem. It is a short patch to files/drives.c and the behaviour is set in a way that "AutoMount = 0" is assumed in the default case making it go along the old execution path. (The newer patch is cleaned up for submission (including to untabify it)).

I would like to see this patch in standard wine cvs now to allow people using automounted floppy/cdrom to use wine without problems - and in the way a user would expect it from windows. Btw, the wine cvs looks pretty good now for common usage of our programs, just this automounter problem needs us to patch the sources.

Patch regenerated:



First creation of the patch
Standard patch with some wine RPMs
Cleaning up the patch for submission
Creating bug report #1283 on
On request, adding documentation patches
After hint on WWN about patch style:
Regnerated the patch (again, apply with `patch -p0`)