5.5. The Wine File System And Drive Layer

5.5.1. Extremely Important Prerequisites

If you're planning to include access to a CD-ROM drive in your Wine configuration on Linux, then make sure to add the "unhide" mount option to the CD-ROM file system entry in /etc/fstab, e.g.:
/dev/cdrom /cdrom  iso9660 ro,noauto,users,unhide 0 0
	  
Several Windows program setup CD-ROMs or other CD-ROMs chose to do such braindamaged things as marking very important setup helper files on the CD-ROM as "hidden". That's no problem on Windows, since the Windows CD-ROM driver by default displays even files that are supposed to be "hidden". But on Linux, which chose to hide "hidden" files on CD by default, this is FATAL! (the programs will simply abort with an "installation file not found" or similar error) Thus you should never forget to add this setting.

5.5.2. Short Introduction

Wine emulates drives by placing their virtual drive roots to user-configurable points in the Unix filesystem, so it's your choice where C:'s root should be (tools/wineinstall will even ask you). If you choose, say, ~/wine (or, in other words, /home/user/wine, since "~" indicates the home directory of a user), as the root of your virtual drive C:, then you'd put this into your Wine configuration file:

[Drive C]
"Path" = "${HOME}/wine"
"Type" = "hd"
"Label" = "MS-DOS"
"Filesystem" = "win95"
        

With this configuration, what windows apps think of as "c:\windows\system" would map to /home/user/wine/windows/system in the UNIX filesystem. Note that you need to specify "Filesystem" = "win95", not "Filesystem" = "unix", to make Wine simulate a Windows compatible (case insensitive) filesystem, otherwise most apps won't work.

5.5.3. Windows Directory Structure

Here's the fundamental layout that Windows programs and installers expect and that we thus need to configure properly in Wine. Without it, they seldomly operate correctly. If you intend to use a no-windows environment (not using an existing Windows partition), then it is recommended to use either WineSetupTk's or wineinstall's capabilities to create an initial windows directory tree, since creating a directory structure manually is tiresome and error-prone.

C:\                Root directory of primary disk drive
  Windows\         Windows directory, containing .INI files,
                     accessories, etc.
    System\        Win3.x/95/98/ME directory for common DLLs
                     WinNT/2000 directory for common 16-bit DLLs
    System32\      WinNT/2000 directory for common 32-bit DLLs
    Start Menu\    Program launcher directory structure
      Programs\    Program launcher links (.LNK files) to programs
  Program Files\   Application binaries (.EXE and .DLL files)

5.5.4. The [Drive x] Sections

These sections are supposed to make certain Unix directory locations accessible to Wine as a DOS/Windows drive (drive 'x:') and thus accessible to Windows programs under the drive name you specified. Every DOS/Windows program sort of expects at least a C: drive (and sometimes also an A: floppy drive), so your configuration file should at least contain the corresponding sections, [Drive C] and [Drive A]. You need to decide on whether you want to use an existing Windows partition as the C drive or whether you want to create your own Wine drive C directory tree somewhere (take care about permissions!). Each drive section may specify up to 6 different settings as explained below.

[Drive x]
The above line begins the section for a drive whose letter is x (DOS notation: drive 'x:'). You could e.g. create an equivalent to a drive 'C:' under DOS/Windows by using a [Drive C] section name. Note that the drive letter is case insensitive.

"Path" = "/dir/to/path"
This specifies the directory where the drive will begin. When Wine is browsing in drive x, it will be able to see the files that are in the directory /dir/to/path and below. (note that symlinks to directories won't get included! see "ShowDirSymlinks" configuration setting) You can also make use of environment variables like $HOME here, an example for using a mywinedrive directory in your home dir would be
"Path" = "${HOME}/mywinedrive"
Don't forget to leave off the trailing slash!

"Type" = "hd|cdrom|network|floppy"
Sets up the type of drive Wine will see it as. Type must equal one of the four floppy, hd, cdrom, or network. They are self-explanatory. (The |'s mean "Type = '<one of the options>'".) Usually, you choose "hd" for a drive ("hd" is default anyway). For a home directory entry, it makes sense to choose "network" sometimes, since some home directories are being exported over the network via NFS and thus can have slow response times.

"Label" = "blah"
Defines the drive label. Generally only needed for programs that look for a special CD-ROM. The label may be up to 11 characters. Note that the preferred way of managing labels and serial numbers of CD-ROMs and floppies is to give Wine raw device access for reading these on a per-CD case (see "Device" below) instead of hardcoding one specific "Label".

"Serial" = "deadbeef"
Tells Wine the serial number of the drive. A few programs with intense protection for pirating might need this, but otherwise it's not needed. Up to 8 characters and hexadecimal. Using a "Device" entry instead of hardcoding the "Serial" probably is a smarter choice.

"Filesystem" = "win95|unix|msdos"
Sets up the way Wine looks at files on the drive. This setting controls the file name lookup and mapping of Wine to existing file systems on your PC, it does not tell anything about the filesystem used itself.

win95

Case insensitive. Alike to Windows 9x/NT 4. This is the long filename filesystem you are probably used to working with. The filesystem bæhaviour of choice for most programs to be run under wine. Probably the one you want!

unix

Case sensitive. This filesystem has almost no use (Windows apps expect case insensitive filenames), except maybe for Winelib applications. Try it if you dare, but win95 is a much better and always recommended choice.

msdos

Case insensitive filesystem. Alike to DOS and Windows 3.x. 8.3 is the maximum length of files (eightdot.123) - longer ones will be truncated.

Note: This is a very bad choice if you plan on running apps that use long filenames. win95 should work fine with apps that were designed to run under the msdos system. In other words, you might not want to use this.

"Device" = "/dev/xx"

Needed for raw device access and label and serial number reading. Use this only for floppy and cdrom devices. Using it on Extended2 or other Unix file systems can have dire results (when a windows app tries to do a lowlevel write, they do it in a FAT way -- FAT format is completely different from any Unix file system). Also, make sure that you have proper permissions to this device file.

Note: This setting is not really important; almost all apps will have no problem if it remains unspecified. For CD-ROMs it's quite useful in order to get automatic label detection, though. If you are unsure about specifying device names, just leave out this setting for your drives.

Here are a few sample entries:
Here is a setup for Drive C, a generic hard drive:
[Drive C]
"Path" = "/dosc"
"Type" = "hd"
"Label" = "Hard Drive"
"Filesystem" = "win95"
This is a setup for Drive E, a generic CD-ROM drive:
[Drive E]
"Path" = "/mnt/cdrom"
"Type" = "cdrom"
"Label" = "Total Annihilation"
"Filesystem" = "win95"
"Device" = "/dev/cdrom"
And here is a setup for Drive A, a generic floppy drive:
[Drive A]
"Type" = "floppy"
"Path" = "/mnt/floppy"
"Label" = "Floppy Drive"
"Serial" = "87654321"
"Filesystem" = "win95"
"Device" = "/dev/fd0"
          

5.5.5. File system settings in the [wine] section

"Windows" = "c:\\windows"
This tells Wine and Windows programs where the Windows directory is. It is recommended to have this directory somewhere on your configured C drive, and it's also recommended to just call the directory "windows" (this is the default setup on Windows, and some stupid programs might rely on this). So in case you chose a "Windows" setting of "c:\\windows" and you chose to set up a drive C e.g. at /usr/local/wine_c, the corresponding directory would be /usr/local/wine_c/windows. Make one if you don't already have one. No trailing slash (not C:\\windows\)! Write access strongly recommended, as Windows programs always assume write access to the Windows directory!

"System" = "c:\\windows\\system"
This sets up where the windows system files are. The Windows system directory should reside below the directory used for the Windows setting. Thus when using the example above, the system directory would be /usr/local/wine_c/windows/system. Again, no trailing slash, and write access!

"Temp" = "c:\\temp"
This should be the directory you want your temp files stored in, /usr/local/wine_c/temp in our example. Again, no trailing slash, and write access!!

"Path" = "c:\\windows;c:\\windows\\system;c:\\blanco"
          

Behaves like the PATH setting on UNIX boxes. When wine is run like wine sol.exe, if sol.exe resides in a directory specified in the Path setting, wine will run it (Of course, if sol.exe resides in the current directory, wine will run that one). Make sure it always has your windows directory and system directory (For this setup, it must have "c:\\windows;c:\\windows\\system").

"ShowDirSymlinks" = "1"
          
Wine doesn't pass directory symlinks to Windows programs by default, as doing so may crash some programs that do recursive lookups of whole subdirectory trees whenever a directory symlink points back to itself or one of its parent directories. That's why we disallowed the use of directory symlinks and added this setting to reenable ("1") this functionality. If you really need Wine to take into account symlinked directories, then reenable it, but be prepared for crashes in certain Windows programs when using the above method! (in other words: enabling it is certainly not recommended)

5.5.6. More detailed explanation about file system differences

Windows uses a different (and inferior) way than Unix to describe the location of files in a computer. Thus Windows programs also expect to find this different way supported by the system. Since we intend to run Windows programs on a Unix system, we're in trouble, as we need to translate between these different file access techniques.

Windows uses drive letters to describe drives or any other form of storage media and to access files on them. For example, common drive names are C: for the main Windows system partition on the first harddisk and A: for the first floppy drive. Also, Windows uses \ (backslash) as the directory separator sign, whereas Unix uses / (slash). Thus, an example document on the first data partition in Windows might be accessed by the name of D:\mywork\mydocument.txt.

So much for the Windows way of doing things.

Well, the problem is, in Unix there is no such thing as "drive letters". Instead, Unix chose to go the much better way of having one single uniform directory tree (starting with the root directory /), which has various storage devices such as e.g. harddisk partitions appended at various directory locations within the tree (an example would be /data1/mywork, which is the first data partition mounted/attached to a directory called data1 in the root directory /; mywork is a sub directory of the data partition file system that's mounted under /data1). In Unix, the Windows example document mentioned above could e.g. be accessed by the name of /data1/mywork/mydocument.txt, provided that the administrator decided to mount (attach) the first data partition at the directory /data1 inside the Unix directory tree. Note that in Unix, the administrator can choose any custom partition location he wants (here, /data1), whereas in Windows the system selects any drive letter it deems suitable for the first data partition (here, D:), and, even worse, if there is some change in partition order, Windows automatically changes the drive letter, and you might suddenly find yourself with a first data partition at drive letter E:, with all the file naming and referencing confusion that entails. Thus, the Windows way of using ever-changing drive letters is clearly inferior to the Unix way of assigning fixed directory tree locations for every data storage medium. As we'll see soon, fortunately this Windows limitation of changing drive letters doesn't affect us in Wine at all, since we can properly map never-changing drive letters to fixed locations inside the Unix directory tree (and even if the location of the respective Unix directory changes, we can still simply update the Wine drive mapping to reflect the updated location and at the same time keep the original drive letter).

OK, now that we know some theory about Windows and Unix drive and filename mapping, it's probably time to ask how Wine achieves the magic of mapping a Unix directory location to a Windows drive...

Wine chose to do the following: In Wine, you don't assign some real physical storage medium (such as a harddisk partition or similar) to each drive letter mapping entry. Instead, you choose certain sub directory trees inside the Unix directory tree (that starts with /) that you would like to assign a drive letter to.

Note that for every Unix sub directory tree that you intend to start Windows programs in, it is absolutely required to have a Wine drive mapping entry:

For example, if you had a publicly writable "Windows directory space" under /usr/mywine, then in order to be able to access this sub directory tree from Wine, you should have a drive mapping entry that maps a certain drive letter (for example, let's take drive letter P:) either to /usr/mywine or /usr (to also access any directories belonging to the parent directory) or / (to also access any directory whatsoever on this system by this drive letter mapping). The DOS drive/directory location to access files in /usr/mywine in Wine in these configuration cases would then be P:\ or P:\mywine or P:\usr\mywine, respectively.

5.5.7. Installing Wine Without Windows

Written by James Juran

(Extracted from wine/documentation/no-windows)

A major goal of Wine is to allow users to run Windows programs without having to install Windows on their machine. Wine implements the functionality of the main DLLs usually provided with Windows. Therefore, once Wine is finished, you will not need to have Windows installed to use Wine.

Wine has already made enough progress that it may be possible to run your target programs without Windows installed. If you want to try it, follow these steps:

  1. Point [Drive C] in ~/.wine/config to the directory where you want C: to be. Refer to the wine.conf man page for more information. The directory to be used for emulating a C: drive will be the base directory for some Windows specific directories created below. Remember to use "Filesystem" = "win95"!

  2. Within the directory to be used for C:, create empty windows, windows/system, windows/Start Menu, and windows/Start Menu/Programs directories. Do not point Wine to a Windows directory full of old installations and a messy registry. (Wine creates a special registry in your home directory, in $HOME/.wine/*.reg. Perhaps you have to remove these files). In one line: mkdir -p windows windows/system windows/Start\ Menu windows/Start\ Menu/Programs

  3. Run and/or install your programs.

Because Wine is not yet complete, some programs will work better with native Windows DLLs than with Wine's replacements. Wine has been designed to make this possible. Here are some tips by Juergen Schmied (and others) on how to proceed. This assumes that your C:\windows directory in the configuration file does not point to a native Windows installation but is in a separate Unix file system. (For instance, "C:\windows" is really subdirectory "windows" located in "/home/ego/wine/drives/c").

5.5.8. Installing Wine Using An Existing Windows Partition As Base

Some people intend to use the data of an existing Windows partition with Wine in order to gain some better compatibility or to run already installed programs in a setup as original as possible. Note that many Windows programs assume that they have full write access to all windows directories. This means that you either have to configure the Windows partition mount point for write permission by your Wine user (see Dealing with FAT/VFAT partitions on how to do that), or you'll have to copy over (some parts of) the Windows partition content to a directory of a Unix partition and make sure this directory structure is writable by your user. We HIGHLY DISCOURAGE people from directly using a Windows partition with write access as a base for Wine!! (some programs, notably Explorer, corrupt large parts of the Windows partition in case of an incorrect setup; you've been warned). Not to mention that NTFS write support in Linux is still very experimental and dangerous (in case you're using an NT-based Windows version using the NTFS file system). Thus we advise you to go the Unix directory way.

5.5.9. Dealing With FAT/VFAT Partitions

Written by Steven Elliott

(Extracted from wine/documentation/linux-fat-permissions)

This document describes how FAT and VFAT file system permissions work in Linux with a focus on configuring them for Wine.

5.5.9.1. Introduction

Linux is able to access DOS and Windows file systems using either the FAT (older 8.3 DOS filesystems) or VFAT (newer Windows 95 or later long filename filesystems) modules. Mounted FAT or VFAT filesystems provide the primary means for which existing programs and their data are accessed through Wine for dual boot (Linux + Windows) systems.

Wine maps mounted FAT filesystems, such as /c, to driver letters, such as "c:", as indicated by the ~/.wine/config file. The following excerpt from a ~/.wine/config file does this:

  [Drive C]
  "Path" = "/c"
  "Type" = "hd"
          

Although VFAT filesystems are preferable to FAT filesystems for their long filename support, the term "FAT" will be used throughout the remainder of this document to refer to FAT filesystems and their derivatives. Also, "/c" will be used as the FAT mount point in examples throughout this document.

Most modern Linux distributions either detect or allow existing FAT file systems to be configured so that they can be mounted, in a location such as /c, either persistently (on bootup) or on an as needed basis. In either case, by default, the permissions will probably be configured so that they look like:

  ~>cd /c
  /c>ls -l
  -rwxr-xr-x   1 root     root           91 Oct 10 17:58 autoexec.bat
  -rwxr-xr-x   1 root     root          245 Oct 10 17:58 config.sys
  drwxr-xr-x  41 root     root        16384 Dec 30  1998 windows
          

where all the files are owned by "root", are in the "root" group and are only writable by "root" (755 permissions). This is restrictive in that it requires that Wine be run as root in order for programs to be able to write to any part of the filesystem.

There are three major approaches to overcoming the restrictive permissions mentioned in the previous paragraph:

  1. Run Wine as root

  2. Mount the FAT filesystem with less restrictive permissions

  3. Shadow the FAT filesystem by completely or partially copying it

Each approach will be discussed in the following sections.

5.5.9.2. Running Wine as root

Running Wine as root is the easiest and most thorough way of giving programs that Wine runs unrestricted access to FAT files systems. Running wine as root also allows programs to do things unrelated to FAT filesystems, such as listening to ports that are less than 1024. Running Wine as root is dangerous since there is no limit to what the program can do to the system, so it's HIGHLY DISCOURAGED.

5.5.9.3. Mounting FAT filesystems

The FAT filesystem can be mounted with permissions less restrictive than the default. This can be done by either changing the user that mounts the FAT filesystem or by explicitly changing the permissions that the FAT filesystem is mounted with. The permissions are inherited from the process that mounts the FAT filesystem. Since the process that mounts the FAT filesystem is usually a startup script running as root the FAT filesystem inherits root's permissions. This results in the files on the FAT filesystem having permissions similar to files created by root. For example:

  ~>whoami
  root
  ~>touch root_file
  ~>ls -l root_file
  -rw-r--r--   1 root     root            0 Dec 10 00:20 root_file
          

which matches the owner, group and permissions of files seen on the FAT filesystem except for the missing 'x's. The permissions on the FAT filesystem can be changed by changing root's umask (unset permissions bits). For example:

  ~>umount /c
  ~>umask
  022
  ~>umask 073
  ~>mount /c
  ~>cd /c
  /c>ls -l
  -rwx---r--   1 root     root           91 Oct 10 17:58 autoexec.bat
  -rwx---r--   1 root     root          245 Oct 10 17:58 config.sys
  drwx---r--  41 root     root        16384 Dec 30  1998 windows
          

Mounting the FAT filesystem with a umask of 000 gives all users complete control over it. Explicitly specifying the permissions of the FAT filesystem when it is mounted provides additional control. There are three mount options that are relevant to FAT permissions: uid, gid and umask. They can each be specified when the filesystem is manually mounted. For example:

  ~>umount /c
  ~>mount -o uid=500 -o gid=500 -o umask=002 /c
  ~>cd /c
  /c>ls -l
  -rwxrwxr-x   1 sle      sle            91 Oct 10 17:58 autoexec.bat
  -rwxrwxr-x   1 sle      sle           245 Oct 10 17:58 config.sys
  drwxrwxr-x  41 sle      sle         16384 Dec 30  1998 windows
          

which gives "sle" complete control over /c. The options listed above can be made permanent by adding them to the /etc/fstab file:

  ~>grep /c /etc/fstab
  /dev/hda1  /c  vfat  uid=500,gid=500,umask=002,exec,dev,suid,rw 1 1
          

Note that the umask of 002 is common in the user private group file permission scheme. On FAT file systems this umask assures that all files are fully accessible by all users in the specified user group (gid).

5.5.9.4. Shadowing FAT filesystems

Shadowing provides a finer granularity of control. Parts of the original FAT filesystem can be copied so that the program can safely work with those copied parts while the program continues to directly read the remaining parts. This is done with symbolic links. For example, consider a system where a program named AnApp must be able to read and write to the c:\windows and c:\AnApp directories as well as have read access to the entire FAT filesystem. On this system the FAT filesystem has default permissions which should not be changed for security reasons or can not be changed due to lack of root access. On this system a shadow directory might be set up in the following manner:

  ~>cd /
  />mkdir c_shadow
  />cd c_shadow
  /c_shadow>ln -s /c_/* .
  /c_shadow>rm windows AnApp
  /c_shadow>cp -R /c_/{windows,AnApp} .
  /c_shadow>chmod -R 777 windows AnApp
/c_shadow>perl -p -i -e 's|/c$|/c_shadow|g' ~/.wine/config
          

The above gives everyone complete read and write access to the windows and AnApp directories while only root has write access to all other directories.

5.5.10. Drive labels and serial numbers

Written by Petr Tomasek Nov 14 1999

Changes by Andreas Mohr Jan 25 2000

(Extracted from wine/documentation/cdrom-labels)

Until now, your only possibility of specifying drive volume labels and serial numbers was to set them manually in the wine configuration file. By now, wine can read them directly from the device as well. This may be useful for many Win 9x games or for setup programs distributed on CD-ROMs that check for volume label.

5.5.10.1. What's Supported?

File SystemTypesComment
FAT systemshd, floppyreads labels and serial numbers
ISO9660cdromreads labels and serial numbers (not mixed-mode CDs yet!)

5.5.10.2. How To Set Up?

Reading labels and serial numbers just works automagically if you specify a "Device" = line in the [Drive x] section in your ~/.wine/config. Note that the device has to exist and must be accessible by the user running Wine if you do this, though.

If you don't want to read labels and serial numbers directly from the device, then you should give fixed "Label" = or "Serial" = entries in ~/.wine/config, as Wine returns these entries instead if no device is given. If they don't exist, then Wine will return default values (label Drive X and serial 12345678).

If you want to give a "Device" = entry only for drive raw sector accesses, but not for reading the volume info from the device (i.e. you want a fixed, preconfigured label), you need to specify "ReadVolInfo" = "0" to tell Wine to skip the volume reading.

5.5.10.3. Examples

Here's a simple example of CD-ROM and floppy; labels will be read from the device on both CD-ROM and floppy; serial numbers on floppy only:

      [Drive A]
      "Path" = "/mnt/floppy"
      "Type" = "floppy"
      "Device" = "/dev/fd0"
      "Filesystem" = "msdos"

      [Drive R]
      "Path" = "/mnt/cdrom"
      "Type" = "cdrom"
      "Device" = "/dev/hda1"
      "Filesystem" = "win95"
        

Here's an example of overriding the CD-ROM label:

      [Drive J]
      "Path" = "/mnt/cdrom"
      "Type" = "cdrom"
      "Label" = "X234GCDSE"
      ; note that the device isn't really needed here as we have a fixed label
      "Device" = "/dev/cdrom"
      "Filesystem" = "msdos"
        

5.5.10.4. Todo / Open Issues

  • The CD-ROM label can be read only if the data track of the disk resides in the first track and the cdrom is iso9660.

  • Better checking for FAT superblock (it now checks only one byte).

  • Support for labels/serial nums WRITING.

  • Can the label be longer than 11 chars? (iso9660 has 32 chars).

  • What about reading ext2 volume label? ....