Serious bug? File lock not working

K

Khoji

Member
As far as we can see Windows file locks are not being passed through from OSX shares to Parallels VMs. The scenario is as follows: I have two VMs open, one with Vista and one with XP (but it also happens with two XP VMs). I create a file with a Windows application in one of the VMs and store it in the /Public folder of my OSX user account. The application locks the file it has open, so nobody else should be able to open it in anything but read only -- if I open a second instance of the application in the same VM this works. However, if I then open an instance of the application in the second VM and open the same file it is not locked. The lock is not being passed through by Parallels.

We wrote a test application to test this that can run through all possible Windows file lock scenarios, including read, read/write and write for OpenMode, and ShareExclusive, ShareDenyWrite, ShareDenyRead for ShareMode, plus Lock, DoubleLock and DoubleLockEX for locking. In all cases it is ALWAYS possible to open the locked file in the second instance of Parallels.

Since locking is working in two instances of the same program in the same Parallels VM this demonstrates that Windows file locking IS working on the OSX share. My guess is that what is happening is that Parallels is cacheing the file reads in each VM to speed up read/write operations and not updating the cache when the file is changed in the other VM. So when I "access" the file in the second VM I am actually accessing the cached read-ahead copy, which does not yet have a file lock on it.

Unfortunately, this "unlocked" state persists when the file is written, making it possible for two instances of programs in two VMs to trash each other's writes by overwriting them, even though the files are officially locked.

If this is what is happening it would be quite a serious bug and security hole. Can anyone confirm this?
 
Khoji said:
We wrote a test application to test this that can run through all possible Windows file lock scenarios, including read, read/write and write for OpenMode, and ShareExclusive, ShareDenyWrite, ShareDenyRead for ShareMode, plus Lock, DoubleLock and DoubleLockEX for locking. In all cases it is ALWAYS possible to open the locked file in the second instance of Parallels.
Click to expand...


Thats sad, looks like an easy way to currupt files by accident.
 
bi11 said:
Have you gotten any reply maybe privately from Parallels support yet?
Click to expand...
Zero. No response whatsoever -- my feeling is that they probably know about it and are hoping that nobody will notice the thread. We've tested this very thoroughly and the file locks are never passed through to separate Parallels VMs accessing the same files on the same shares. They can all write with impunity even though the other instances also have the files open.
 
Since you have done all the work, I would be interested to know if this problems extends to instances of Parallels VM's using(opening) files on a real windows server. From your description of the problem, it would seem that this my be only an issue with Parallels and how they use the MacFuse interface. Maybe this will not be an issue if the files and (filesystem) are served by a real windows OS. Still though this problem should addressed by the Parallels team. I would file a ticket, or whatever they call it. At least then you will have a tracking number for the problem.


http://www.parallels.com/en/support/desktop/request/
 
The problem only occurs when accessing an OSX share from multiple VMs on the host machine. If you access a "real" server there is no problem. For example, I set up an Ubuntu machine running Samba/SMB and the file locks are passed through there without problems. I'll set up a ticket, good idea...
 
Curious: What happens if you access the OS X share via SMB directly to the Mac (i.e. over the shared network, but without Parallels shared folders)?
 
You must log in or register to reply here.
Back
Top