2011/4/12 Jeff Layton <jlayton@xxxxxxxxxx>: > On Sun, 10 Apr 2011 15:44:34 +0400 > Pavel Shilovsky <piastry@xxxxxxxxxxx> wrote: > >> Add wine mount option that switches on WINE-capability mode - forward >> pid of a process who opened a file to any read and write operation. >> >> This can prevent WINE program from failing on read or write operation >> on a previously locked file region from the same file descriptor, because >> while a run of WINE program two processes work on the same file descriptor: >> 1) WINE-application does read and write on a file; >> 2) WINE-server does open and lock. >> >> Also switch on strictcache and forcemand modes because WINE needs to work >> with mandatory brlocks and does read and write operations correctly with >> them. >> >> Signed-off-by: Pavel Shilovsky <piastry@xxxxxxxxxxx> > > As a general rule, I'm not too fond of enshrining application behavior > into a mount option like this. What if wine changes their > implementation in the future? I don't think that WINE will change such an architecture thing but, if it will happen, I don't see any problems to change 'wine' mount options behavior for cifs too. Anyway, it is better to support existing WINE than don't do it, I think. > > Would it make more sense to have one mount option that enables this > new mode of PID handling, and keep forcemand and strictcache separate? So, I agree that having these mount options separately is more flexible, but I can't imagine how WINE can be correctly used without forcemand and strictcache mount options on cifs for applications that use brlocks actively. Anyway, I don't insist on it. Steve, Shirish, Suresh, what do you think about it? -- Best regards, Pavel Shilovsky. -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
