Locking, ad nauseum

There have been many threads regarding file locking, and I am going to add another. If this particular topic has already been discussed, I apologize in advance.

When a file lock is set up in TeamSite, but people make their edits using an application outside of TeamSite and copy a new version through a network, or however they do it, into a TeamSite workarea via the filesystem, the lock is essentially ignored. I'm curious if this is a limitation of how TeamSite can control the filesystem or what? I am no expert in UNIX, but I would think that TeamSIte could understand the properties of a file in the filesystem and know who is trying to write over a particular file and resist if the file is locked. Obviously that is not so easy, and may be impossible. I'm just wondering why.

I was able to place a lock on a file, the lock being owned by a user other than myself. Then I created a file with the same name in Windows, copied the file over to the Solaris server in the workarea over the top of the locked file. No problem at all. To me, this is a hole since most users use external applications to edit their content.

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

Find more posts tagged with

Comments

james1

With the "submit locking" model, the file system interface essentially ignores locks.

If you want the file system interface to be more strict, then you could employ the "mandatory write locking" model. This would make all unlocked files read-only.

-- James

james1

PS - I think that the mandatory write locking model has negative effects on performance.

Migrateduser

So, in other words, with Mandatory Write Locking, if someone wanted to use an external application to edit a file in a workarea, or overwrite a file in a workarea he has created outside of TeamSite, he first has to manually unlock the file in the workarea? If that's the case, the users would never go for that. What would be ideal is if a file is locked, by whichever locking model, and someone who doesn't own the lock tries to overwrite that file by some method other than the TeamSite editor, he is unable to do so.

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

james1

With Mandatory Write Lock, all files start off read-only (both in WebDesk and in the file system interface). When you lock a file, it becomes writable (both in WebDesk and in the file system interface).

Therefore, if you are using the file system interface, you cannot write to a TeamSite file until you lock it, either via WebDesk or via the iwlock CLT or via an OpenAPI call.

-- James

Bowker

However, that's kinda exactly what Smitty didn't want. (I think)

He wants the file to be readonly when locked (unless you are the user who has it locked).

That way if I lock a file, make changes, and while waiting for approval someone else could make changes!

How about not allowing anyone to map \\server\iwserver remotely. Then all access to files would have to be through TS. (don't forget ftp access too)

tiroth

I think the other problem is that the TS interface is very slow for certain tasks, so it is desirable to 1.) allow certain people to map the filesystem, while 2.) maintaining the locking model.

The mandatory locking behavior achieves #2 at the cost of #1 (still have to use the GUI to lock it). Not mapping the y:\ drive does the same.

Migrateduser

My CM philosophy includes the principle that a developer should never be prevented from changing a source file in their own workarea. As long as you can control what gets submitted into the STAGING area, AFAIK, there's no real need to prevent changes to a workarea.

We are using workflow to arbitrate what changes can get into STAGING; but still allow developers to change any file in their own workarea. If there's some reason this wouldn't work for you, let me know and I'll see if I can come up with anything helpful

Migrateduser

We have multiple developers working in the same workarea. Plus FTP users writing files into workareas from remote servers. That's our setup. If every developer had their own workarea, I wouldn't have this problem, but I'd have other problems.

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

StrsPrint.zip

Migrateduser

Could you elaborate on what those other problems would be?

The workflow solution I referred to earlier can deal with such items as unmergeable binary files by locking out subdirectory trees. It could even be used to lock specific files; though I haven't actually done that due to the difference I expect to see in performance between locking directories vs. locking files.

Migrateduser

I don't know what those problems would be as that is not our setup and I would only be guessing. Changing our entire branching/workarea scheme to maybe solve a locking issue is not an option.

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

tvaughan

The "other problem" in having everyone get their own workareas (which is what we do) are:

1) license issues. Interwoven, inc. wants everyone with a workarea to count as a PowerUser license now :-(

2) Training issues. Users get confused as **** when they are suddenly responsible for conflict resolution, and they never notice the difference between a "padlock" icon and a "key" icon !

C'est la vie.

Tom

Migrateduser

This issue is still rearing its ugly head for me. I need to lock files in TeamSite at a certain point in my workflow. Everyone who puts files into TeamSite does so via FTP or Samba from their own PCs. No one uses TeamSite to add or edit files. The Mandatory Write Lock model will not work for me because it requires people to lock files prior to moving them to TeamSite. If they wanted to log into TeamSite to lock files, they might as well log into TeamSite and upload the files. I'll say it again - they work on their PC and FTP or Samba files to TeamSite. That's not negotiable.

It appears that any TeamSite lock requires some manual or programmatic initiation to create the lock. Once the lock is in place, it is only effective when someone attempts to manipulate the locked file within TeamSite. Copying a file over the top of a locked file in the filesystem is not prohibited by the lock. The lock is essentially ignored.

So has anyone ever dealt with this issue? I'm thinking the only way around it is to use setuid to set up a script to run as root and modify the file permissions so that no one can write over the files unless they are the file owner. That seems rather extreme but it's the only thing I can think of.

Please let me know if you have handled this scenario successfully. I'm open to ideas.

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

james1

I don't know any suitable solutions for your problem, but I thought I should comment on one point:

> Once the lock is in place, it is only effective when
> someone attempts to manipulate the locked file within
> TeamSite. Copying a file over the top of a locked file in
> the filesystem is not prohibited by the lock. The lock is
> essentially ignored.

It sounds like your definition of lock is "grants exclusive write permissions to a user". In fact, it is, for the submit locking model, "grants exclusive submit permissions on this branch to a workarea". I assure you that the lock is not ignored.

-- James

--
James H Koh
Interwoven Engineering

Migrateduser

My definition of a lock is that no one other than the owner should be able to write over or modify that file. It certainly would be nice if this was possible.

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

Migrateduser

Submit locking is essentially useless to me since I want the file locked about 10 tasks prior to my submittask. When I decide I want the file locked, I want it locked then. Not at submit time.

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

johnjamesmarsh

I'll add my bit now too.

I have much the same problem as I have editors who are doing normal changes and a developer who is doing DDA (disability discrimination act) changes to all the pages via the file system. The DDA changes don't lock the files so the editors don't know that they are not using the latest version of the file. The problem will disappear after the weekly release but the editorial team now cannot start any new work for the week after.

What I want, and I think everyone else wants too, is that when you edit a file via the file system the file is locked there and then, i.e. I go to Windows Explorer, double click a file on the Teamsite samba mount, make my edits and then save the file at which point the file gets locked. If someone edits the file via the Teamsite GUI in the mean time then my save fails. If someone else has saved the file through the samba mapping then the my save fails.

This kind of functionality would turn Teamsite into a seriously useful product. The system must be able to do this as it knows the file has been modified. The icon changes, why doesn't the lock status?!?!?!?!

John

Migrateduser

Thank goodness I'm not the only one feeling the pain. Evidently TeamSite does not consider a locked file as one that no one else can mess with. It seems fairly simple to me that when you set a file to be locked, the file permissions would be temporarily changed to disallow anoyne else from modifying that file. That takes care of anyone editing files from outside of TeamSite as well as inside. That's what I need.

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

JonathonG

I think what we have here is different definitions of what it means for a file to be "locked".

To reiterate what was said earlier, a "lock" in the submit locking model means you have reserved the right to submit the file. No one else will be able to submit the file you have locked.

A "lock" in Mandatory Write Locking means you are the only one who can edit the file. This is what your most recent post seems to be asking for. Of course, this also requires that you be able to lock the file prior to editing it, i.e. declare your intentions first.

It would seem to me that what you are asking for (by reading the rest of the thread) is Mandatory Write Locking, with auto-lock on first edit if not already locked. This brings up all kinds of concurrency issues, however. If user A makes 100 changes to file X, then clicks save and at the same time user B makes 100 different changes to file X and clicks save, who's changes get saved? Obviously, it would be the one the server perceived as getting in "first." The other user is simply out of luck and their changes are stuck in the buffer of whatever application they are using (best case). Additionally, this turns every save into a multi-step operation of: check the lock, [optionally] lock the file, write the data to disk. I'm fairly certain this would negatively impact performance and may introduce nasty race conditions.

All that being said, I suppose you could contact support about a feature request for this.

Not sure if this helps or if its just rambling,

Jonathon
Interwoven Architecture Consultant

Migrateduser

I understand what you're saying, and I can see why you came to those conclusions based on what I said. However I think I'm asking for something in-between. Because all of our users push files to our TeamSite server remotely, locking during first edit is not really what I'm asking for, since they are editing their files on their local PC. I would want the file to be locked as soon as it was copied over to the TS server and marked as "having been modified". Maybe that's the same thing - I'm not sure when TS considers a file to be modifed - when it is opened or when it is saved. Regardless, what I said seems different than what you said, but maybe that's just because we're looking at this from different directions.

The mandatory write lock concept could potentially work if it was easy to perform the lock remotely. Even then it would suck to have to expect the users to lock first then push their files over. LAutomatically locking the file upon the push would be most desirable. It would also give them feedback immediately if the file has been locked before their push - they would be denied.

Even more importantly, I would like the Lock command, whether it be from the TS menu or CLT, to lock a file in the manner I described, disallowing anyone from editing (opening or overwriting) that file until the lock is released. I don't think this is an unreasonable expectation when a file is marked as locked.

Let me also reiterate why the Submit Locking Model is useless to me. We do not ever submit until we're ready to push to production. The file is in the workarea through the QA process and prior to QA we absolutely do not want anyone to touch that file in the workarea. So it's very important that we be able to lock the file from any edits and overwrites while it's still in the workarea, and several steps away from being submitted.

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

Edited by Smitty77 on 07/07/03 01:43 PM (server time).

JonathonG

Well, I think I understand now what you're looking for. Basically, I believe mandatory write locking would solve your problem if there was a remote way to lock a file. That is probably a much simpler feature request than some kind of auto-lock on modify (modify in this case meaning file written to TS filesystem, be it by a save or an ftp upload).

<philosophy mode="on">
From a philosophical standpoint, I think a lock on modify is a bad idea. The normal TeamSite interface locks a file upon first request for edit (clicking the "edit file" button in the GUI). This ensures that while you are editing the file, everyone else knows it. In the case of haveing the files offline, editing, and then uploading (with an automatic lock applied), it would seem that there is no way anyone can know what someone else is working on until they've uploaded their changes. A simple step of locking the file first would go a long way toward better communication and tracking of what's going on in the site. Out of curiosity, what is the expected behavior if two users spend several hours each on the same file and then try to upload it? I can't imagine any real good answers to that unless they've been communicating in some way (and lock-first is a good communication mechanism).
</philosophy>

I would think a simple CGI to lock a file should be fairly easy to write and you could give that to the users as the first step in their process.

Jonathon
Interwoven Architecture Consultant

johnjamesmarsh

Hmmm, I think we need to take a step away from the philosophy and look at the practicality.

Fact: Users edit files by using the file system
Fact: Users 'forget' to lock the file through Teamsite before they edit them through the file system

I think it would be easier to change Teamsite than human nature (though I could be wrong on this one). You suggest a CGI. Would that be automatic? Or could users still forget?

There are events that gets fired when a file is modified aren't there? CreateFSE, DestroyFSE, ModifyFSE and RenameFSE spring to mind as events that might be useful. Turning them on using the current mechanism looks like it would be possible but an Interwoven implemented solution would be muchly preferred.

Regards

John

Migrateduser

I have to agree with this. There's little chance I can get the dozens upon dozens of remote users to remember to lock a file before copying it over to TeamSite. These people work in Dreamweaver and use Dreamweaver to FTP their files over. It's a seamless operation right now. I'm expecting the content management system to handle file locking the way I require it. From what I can tell, other TeamSite users want less TS GUI and more "work in my own environment" interface. I really don't think my scenario is all that bizarre. It can't be that unusual for people to not edit their files directly through the TeamSite GUI. We save a lot of money on user licenses this way. Although it is unlikely that two different people would be making changes to the same file, it's not good enough to just wish it doesn't happen. We need this file locking ability to absolutely ensure it in order to meet the requirements of our customer. The fact that TeamSite doesn't provide this type of locking is extremely disappointing.

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

JonathonG

I hear what you are both saying. And as I said before, this sounds like something you could file as a feature request. However, I think there's one thing that doesn't seem to be clear.

Smitty, you say,

"Although it is unlikely that two different people would be making changes to the same file, it's not good enough to just wish it doesn't happen. We need this file locking ability to absolutely ensure it in order to meet the requirements of our customer. "

I would contend that what you are asking for does not ensure that it won't happen. It just pushes the problem back a level. With what you have now, people can make changes in their own Dreamweaver session and ftp it to TeamSite. Two different people could do this and overwrite each others work on the server. I would agree that this is a bad thing. However, if the file were to go read-only upon the first person uploading, the second person would get errors on uploading. This has *not* prevented the two people from editing that file. It has simply moved the problem back onto their local hard drive. Let's say that user 2 just spent 3 days working on his changes. Now they're useless? Or what is he to do about it? I still contend that its better to know up front that I'm gonna get to save my changes to the sever.

As for the idea of users "forgetting" to lock the file, this is easily solved using a write-lock model. If they forget, they won't be able to upload. Put each user in their own workarea and give them some easy way to lock a file (another feature request might be to get some sort of integration between Dreamweaver and TeamSite so that "lock" is a DW menu or such).

<sarcasm>
Then again, if your goal is to "save a lot of money on user licenses," I can see why you wouldn't want the users to actually "use" the CMS.
</sarcasm>

Jonathon
Interwoven Architecture Consultant

Migrateduser

It's not a goal to have less user licenses, it's merely a convenient byproduct. Sarcasm or not.

The ultimate result of why I need this type of file locking is to ensure someone who has changed a file and has started a workflow to move their changes through to production will not get those changes overwritten in the middle of the workflow. The potential for someone else to get a little irritated if they happened to make changes to the same file(s) only to find out the file(s) are locked is a secondary issue and not even remotely as significant. I simply don't like the idea of having the users lock remotely prior to FTPing - that will imply they have to log into TeamSite somehow and that is undesirable.

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