File locking

Wine provides full Windows-compatible file locking capabilities. There are two possible interpretation of the term "file locking." This article only attempts to deal with the file region locking, rather than the read/write sharing/access rights. The file region implementation is in wineserver in server/fd.c, but wineserver executes per user only and it doesn't share locked file information between users.

As much of the file locking as possible is done at the file system level, but the only filesystem that supports the Windows style locking semantics is smbfs. The rest we have to emulate in the wineserver. The wineserver isn't currently shared between processes, but Alexandre is doing work towards making this possible and Rob is doing work on the security side to make it safe to. One alternative is a shared locking server (as suggested by the Samba team). AFAIK, no one has started implementing their suggestion. A variation on this could be a shared wineserver that uses

Right solution

Shared wineserver is the right solution, possibly still talking to the samba locking server. However, I believe that it is unlikely that users will be running wine on the same machine as a samba server. For a further extension on the shared wineserver approach, see KernelHandleSupport.

Advantages:

• Correct Windows-like solution with no duplicated code or processes and no hacks.

Disadvantages:

• May be months before it is working.
• Still then, may not be possible on production machines because of security concerns.

Light solution

I propose light solution for multiuser lock support: start existing wineserver as an independent service under special user and use it for file locking purposes only. What the objective reasons do not do so? It can be realized with the same code as already exist in wineserver. We can disable this mode during compiling (it depends how we realized wine_server_call specially for file related functions).

Advantages:

• Quick and easy to share existing code
• How do we communicate between the shared wineserver and the real wineservers?

Disadvantages:

• Really hacky

Any suggestions?

Notes

I don't think a shared wineserver is the solution. Shared locking has to work on network filesystems too, so it needs to be based on filesystem locking. This is currently implemented for normal locks but not for sharing modes, though that shouldn't be too hard to fix.

-- Alexandre Julliard

Current state

We (Etersoft) have a modified (patched) linux-cifs module (1.48a version) with extended system call 'open', and have realized access & sharing modes on it. We got full interoperability between Windows and Wine clients. Sources: ftp://updates.etersoft.ru/pub/Etersoft/WINE%40Etersoft-current/sources/linux-cifs-1.48a-alt7.src.rpm

We (Etersoft) have done developing support access & sharing modes based on file locking (as Alexandre mentioned before). It passed internal wine test now. Also we have developed multiuser testing suite for it, see at result:

-- Vitaly Lipatov

Microsoft has a table for valid combination of shared/access modes: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/fs/creating_and_opening_files.asp We are developing test with similar output (it tested on WINE, Windows 2003):

             G_R   G_R   G_R   G_W   G_W   G_W G_R|W G_R|W G_R|W
             S_R   S_W S_R|W   S_R   S_W S_R|W   S_R   S_W S_R|W

       G_R    VL    .     VL    .     .     .     .     .     .
       S_R

       G_R    .     .     .     VL    .     VL    .     .     .
       S_W

       G_R    VL    .     VL    VL    .     VL    VL    .     VL
     S_R|W

       G_W    .     VL    VL    .     .     .     .     .     .
       S_R

       G_W    .     .     .     .     VL    VL    .     .     .
       S_W

       G_W    .     VL    VL    .     VL    VL    .     VL    VL
     S_R|W

     G_R|W    .     .     VL    .     .     .     .     .     .
       S_R

     G_R|W    .     .     .     .     .     VL    .     .     .
       S_W

     G_R|W    .     .     VL    .     .     VL    .     .     VL
     S_R|W

• 'V' means valid combination (good)
• 'L' means lock a file region is works (good)

See at 'V' letter in right bottom which is missed in Microsoft's page.

For other Linux user in wine we have the same picture (see above). Without patch http://www.winehq.org/pipermail/wine-patches/2005-September/020821.html it works as shown below:

             G_R   G_R   G_R   G_W   G_W   G_W G_R|W G_R|W G_R|W
             S_R   S_W S_R|W   S_R   S_W S_R|W   S_R   S_W S_R|W

       G_R   lVX   l.    lVX   l.    l.    l.    l.    l.    l.
       S_R

       G_R   l.    l.    l.    lVX   l.    lVX   l.    l.    l.
       S_W

       G_R   lVX   l.    lVX   lVX   l.    lVX   lVX   l.    lVX
     S_R|W

       G_W   l.    lVX   lVX   l.    l.    l.    l.    l.    l.
       S_R

       G_W   l.    l.    l.    l.    lVL   lVL   l.    l.    l.
       S_W

       G_W   l.    lVX   lVX   l.    lVL   lVL   l.    lVL   lVL
     S_R|W

     G_R|W   l.    l.    lVX   l.    l.    l.    l.    l.    l.
       S_R

     G_R|W   l.    l.    l.    l.    l.    lVL   l.    l.    l.
       S_W

     G_R|W   l.    l.    lVX   l.    l.    lVL   l.    l.    lVL
     S_R|W

• 'X' means it can lock region simultaneously (bad)
• 'l' means it can lock region via unix lock call (good)
• 'C' means we can open file simultaneously, but it is not valid (bad) - fixed now

Workers: AlexandreJulliard, RobShearman, VitalyLipatov