nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Editing a locked file from UNIX

ChuckM

If a user locks a file via the UI, it doesn't appear to make any difference to the actual file permissions in UNIX. The result is that someone can easily edit a file in UNIX even if another user has that file locked. Does anyone have a workaround or fix for this?

Find more posts tagged with

Comments

Migrateduser

Looks like you've already found my other thread on this subject. The only workaround I've found so far is to either force everyone to edit everything through TeamSite (not likely) or create your own lock process somehow by having a script run as root and modify file permissions (risky and a potential maintenance nightmare). Maybe if more of us complain for better locking they might hear us. Especially if it's people other than me.

Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com

ChuckM

You're right Dave. I think we will have to create a command trigger (iwatlock or something like that) that kicks off when a file is locked. I was thinking of having it chown the file to be owned by the user and then chmod it to be 775. The down side of this is that any file locked will probably show up as being modified (even if it is never updated).
I think having a "check out" feature is standard with most CMS. They had better start working on this now because their competitors are more than happy to point out this achillies heel.

IDfOmcrRegulatory.java

workflowsexception.jpg

Migrateduser

I'm just glad you pointed it out. To me this is a security hole, especially since all of my users edit on their PCs and then move their files via Samba to our Solaris TeamSIte server - because we base all our workareas on group permissions, everyone can write over everyone else's stuff, locked or not. If only we had the option of a lock being equivalent to a "checkout" then it would make life so much easier. For me, I'd want the permissons to be more like 755, with the person who locked the file being the new owner of the file. Would be nice to have this be a configurable option, especially since the backing store interfaces so tightly with the file system, you'd think it would be easy for TeamSite to do. I feel your pain, Chuck.

Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com

JonathonG

As I noted in the other post, I believe the effect of this can be achieved with a combination of private workareas and mandatory write locking.

If memory servers correctly, this is pretty close to what ClearCase would do. A file is read-only in a view until it is locked. A particular version of a file can only be locked by one person in one view. But, if two people are sharing a view, they would both be able to edit that locked file (I believe), it's just that ClearCase views tend to be private.

So, if every person has their own (non-shared) workarea, and mandatory write locking is turned on, only the person who locks the file in their workarea will be able to edit it. Shared workareas break this down a bit, as anyone who has access to a particular workarea will be able to edit the locked file. Thus, it's a trade-off. And you could create a mixture of shared/private workareas to achieve what your requirements demand.

Jonathon
Interwoven Architecture Consultant