Hi Tanstaafl, I understand that this is fixed meanwhile, but still wanted to give some short comments.
There are two different mechanisms in place: File locking features from OS/File system, and the OOo file locking system done via the ~lock files. The later was introduced because the first one doesn't work reliable cross platform. So the fix that you found in 3.2 is that it won't result in an error / not writeable document when the lock file can't be created, but file locking from the OS works. This just as an explanation for the file locking mechanisms in place - but I still think it's problematic to give access rights to modify, but not to create: For data safety reasons, no application should modify the original file directly. Most applications update files / documents this way: 1) Write temp file for new document. In %TEMP%, or next to old file. 2) If no error occurs, delete old file and move temp file to old file location (where move means rename in case it's stored next to the file and not in %TEMP%. So with OOo, it works because OOo stores the temp file in %TEMP%, and it doesn't do a delete+move then, but streams the content from the temp file into the old file, to maintain ownership and access rights. Your configuration wouldn't work when an application would store the temp file next to the old file (eg. for performance reasons), or if an application would blindly to delete+move, which also results in creating a new file instead of modify an existing one (from a file system perspective). So just some explanation how the process works - as long as you only use OOo, your configuration can work for you. But once you start using some other ODF processing tools, be prepared that such a configuration can be problematic... Best, Malte. Tanstaafl wrote, On 10/30/10 21:36: > On 2010-10-29 5:20 PM, JOE Conner wrote: >> Lock files are created to prevent two or more different users from >> editing the same file at the same time, and interfering with each >> other's edits. > > I know that - but OOo obviously used to determine this differently, > because it *used* to work fine. > >> It makes no sense to have the lock file saved differently on your >> machine, as this would permit the simultaneous edits that are trying >> to be prevented in the first place. > > Actually, that is true... what I want is for OOo to *fall-back* to the > previous method it used for determining if a file was already opened for > editing when it is unable to create the lock file. > >> To solve your problem, get your IT department to set your write >> permissions properly. It sounds as if you have EDIT but not CREATE >> flags set. > > *I* am the IT department, and the permissions *are* set properly. I want > certain users to be able to *edit* documents that reside in directories > that they do *not* have the ability to create *new* documents in. > > As I said, it worked properly like this for *years* prior to OOo > starting to use lock files like MSO does. Another example of a step > *backwards* in the name of 'progress'. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
