Subj : CVS commit src/sbbs3/nope To : Deuce From : Digital Man Date : Mon Dec 27 2004 02:05 am Re: CVS commit src/sbbs3/nope By: Deuce to Digital Man on Sun Dec 26 2004 10:23 pm > Re: CVS commit src/sbbs3/nope > By: Digital Man to Deuce on Sun Dec 26 2004 02:58:00 > > > Well SMB/CIFS has standardized, cross-platform, file and record locking, > > should (obviously) be supported by all smb/cifs clients and servers (e.g. > > smbfs), regardless of the OS on which they're hosted. > > Right... but for a *nix system to map calls to say lockf() to SMB/CIFS calls > it's just not possible because the lock semantics are different. If for > example, you want an exclusive record lock in *nix, you MUST open with write > intent plus some other semantic weirdness... what I'm suggesting is that > although SMB/CIFS supports specific file/record locking, *nix itself does no > so you'd either need to use some platform-specific SMB/CIFS library in the > program or handle the SMB/CIFS stuff yourself to get correct bahaviour. I'm not sure how to respond, because it does work on smbfs-Linux (when it's not locking up). > Possibly the call deadlock response is caused by the fact that our lock() > implementation uses both flock() and fcntl() locks. Not sure, I'd have to > experiment (after the holidays unfortunately) I don't remember how we go onto this debate, but the fact remains that cross-platform file and record locking has to be supported for mixed-OS (Windows and *nix) Synchronet installations, and smbfs and cifs both supposedly do this. My tests (when they work) confirm that files opened with deny-all/write access on Win32 or records locked on Win32 cannot be opened/read/written on smbfs-Linux and vice versa. If it didn't work, I'd get data corruption. That has never been the problem with smbfs-Linux, just system lock-ups. You seem to be insisting that this is impossible. If that's the case then I should just give up now. :-( digital man Snapple "Real Fact" #157: The first TV soap opera debuted in 1946. .