Modified file flag

I'm curious if anyone knows exactly what triggers Teamsite to flag a file as "Modified" (show the little pencil icon)? Somehow in our environment (TS 5.0.2 on Win2k) we have a situation where several workareas show all the files as modified, even though a compare shows no differences with Staging. Doesn't seem to matter if the file was templated or not.

Some workareas in the same branch do not have this problem, but others do. I'm sure we did something strange to cause the problem, but I haven't figured out how it happened. So, I'm trying to work backward and find out exactly what flags a file as modified so I can reverse the flag. I can't do a Get Latest with overwrite because I don't want to delete files that don't exist in staging and I don't have time to manually do a Get Latest on each file. Normal Get Latest doesn't work because it tells me my workarea has a modified copy. Anyone have any suggestions? Thanks!

Find more posts tagged with

Comments

mogoo

Different extended attributes would flag them as modified, yet the code via the compare screen would look the same. Try looking at File-->File Properties to see if/what ea's are changing...

maureen

james1

Off the top of my head, the following operations would cause TeamSite to think that a workarea file is modified:

(1) Writing contents to the file, even if the contents are identical to what used to be there.
(2) Setting the file attributes of the file (e.g., ownership and permissions, e.g. "chown" and "chmod" on UNIX).
(3) Setting TeamSite Extended Attributes on the file.
(4) "touch"ing the file (e.g., the "touch" UNIX command)
(5) Deleting the file. (Obviously not the case here for you.)

If every file in a workarea seems to have been modified, my initial guess would be that somebody has the TeamSite file system mounted as a mapped drive, and a virus scanning program (or something similar) touched every file it could find.

Try to figure out what user (or users) have access to the affected workarea but do *not* have access to other workareas. And/or, try to find out which users have what directories mapped as network drives on their desktop systems. Users could have /default mapped, or a particular branch, or just their own workarea, or even just one directory inside of one workarea.

Hope this helps.
-- James

--
James H Koh
Interwoven Engineering

Migrateduser

It certainly would be nice if there was a pull-down tool that would tell you precisely what attributes of a file made it appear as modified. It truly sucks having to try and figure it out by staring at permissions and other things I don't really care about. If TeamSite knows that the file is modified, it ought to easily be able to tell me why it thinks so. Provide me with that tool - that would be helpful.

I have the same problem with the Resolve Conflict screen when a submission fails in workflow. Have it tell me exactly what the conflict is so I don't have to spend an hour trying to figure it out for myself. It knows there's a conflict - have it tell me, or at least give me a hint.

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

felipel

Interesting point, but it looks like all the EAs are the same. A compare of the file properties shows that the only differences are the Modified attribute (makes sense) and the Area Security (also makes sense). I'm attaching the HTML from the File Properties screens just in case it would help someone troubleshoot this.

mogoo

you're showing 2 file properties from 2 different workareas... now look at the file properties for the same file in staging... any differences between the staging and workarea?

felipel

Doh...sometimes my brain escapes me. Unfortunately, a comparison against staging shows similar behavior. Only differences are the modified flag and the area security. I'm attaching the source again to make sure I'm not doing something stupid again. Thanks for the help!

felipel

Assuming your guess is correct (which appears to be about the only choice), is there any way to reverse the modified flag? I need to do a "Get Latest" on this directory, bringing down the lastest version of these files but TS won't let me since it thinks they're modified. And, as noted above, using Overwrite won't work because I can't lose the work in progress that hasn't yet been submitted. Any suggestions?

Migrateduser

when you do get-latest, if you select overwrite and _only_ the anamolous modified file that you want to roll back, only it will be overwritten. You don't have to do get-latest on the whole wa at once, so your other unsubmitted WIP is safe.

bw

Bob Walden [bob.walden@interwoven.com]
Interwoven Education Group
IM: Yahoo, MSN bob_walden

felipel

Unfortunately, we're talking about ten thousand files here, so tracking them down one by one isn't feasible.

Bowker

We had a situation where someone did a "search" using a text editor in their workarea which searched every file. That operation "opened" every file and marked them as 'modified'.

james1

I'm going to assume that the only user modifications to your work-in-progress files are content-related, not file attributes or TeamSite Extended Attributes.

One attack is to write a script that recurses through an entire workarea (or the result of iwlistmod) and performs a "diff" on the file in the workarea versus the file in staging. If there is no difference in content, then you can safely get latest with overwrite on the file. From your script you could just invoke "iwupdate -w ...".

If there are differences, then I can think of only two possible explanations for the differences: (1) The version in the workarea is a modified work-in-progress. (2) The version in the workarea has not been modified, but is an older version than the one in staging.

The first class of files you want to leave alone.

The second class of files is trickier. You could ignore them at first, and see if that is acceptable to your users. If the workarea had done a get latest recently, then there won't be many files in this category.

The only way I can think of to differentiate the two classes of files is:

(1) Use the iwattrib CLT to find out what "version" the modified workarea file is. It should report back a string like "/main/your-branch/6+". You could also get this information from the iwrlog CLT.
(2) Compare the modified workarea file to its base version (e.g., /main/your-branch/6). I can think of two ways to do this:
(a) Make a copy of your file. Run the iwrevert CLT to revert back to the base version of the file. Compare the reverted file with your copy.
(b) Run the iwrlog CLT to find an objid for that version of that file. Compare the modified workarea file to that version of that file, which can be found in the ".raw" interface, e.g. /default/.raw/[objid].
(3) If the modified workarea file is the same as its base version, then it can be assumed that it is not a bona fide work-in-progress, so I think you have two options:
(a) Get latest with overwrite. This will cause the user's workarea to be fresher than it used to be.
(b) Copy-to-area with overwrite from a prior edition (if one exists) that contains the base version of the file. You can find this edition in the output from iwrlog.

I can think of one other alternative. Go to your backing store backups, find a backup that doesn't have this problem, and either roll back your entire TeamSite installation to it, or bring that backing store up on another machine, and compare your current workarea contents to the backup workarea, to see which files are actual works-in-progress, and which are phony modified files. Of course, this is error-prone, because a lot of work could have happened between the backup and right now, and it could get lost.

Good luck.
-- James

--
James H Koh
Interwoven Engineering

Adam Stoller

I didn't see this mentioned yet - but if you / your IT folks are backing up your workareas - or running some other kind of monitoring tool over your workareas - these tools sometimes touch attributes like the 'archive' bit on Windows files - and doing this will cause each file so touched to appear as modified.

Unfortunately, once you get the source of the problem taken care of, you'll still probably have to do some long-winded steps to "fix" the existing modifications (diff's, iwupdate's, etc.)

--fish
(Interwoven, Curriculum Development)

Migrateduser

Just a supporting comment to ghoti's post previous to this...

It has been my experience that backup routines and virus scans on any file in the Y: Drive will flip a bit (Parity? Archive?). I just recently discovered that our Network Services department was running backups on Y:, thereby causing every file to appear modified every other day. As soon as the backups stopped, the problem went away.

Cheers,

Dan Pike
Portland General Electric

Migrateduser

Having spent hours and hours and hours (is that days yet?) on permissions issues and version control issues in TeamSite (on Solaris..) I've run into the following cases that make the modified icon show unnecessarily:

A copy-to-area from one workarea to another can produce a pencil icon, even though the files compare to the STAGING area with no differences found. I believe that this was fixed in some post 4.2.1 version (where it happened to me).
OR
if a directory is deleted and then readded (via samba is where it happened to us) this will break/reset the version chain and show all the files in the directory as modified.
OR
a solar flare (not really, but I've had that feeling).

I'm in the middle of running a batch job right now to detect if the files in the workarea are truly modified or merely have the modified flag on and then executing a submit statement to submit them to staging if they're the same. This is done with a script wrapped around the dircmp command.....

I really could be spending my time better developing applications on top of this.