List Modified Files

Hi All,

When i do List Modified it gives me all the list of modified files,but it is giving the list modofied by the root also which is been not modified by root, it is showing so many file with the root user as modified. why is this hapenning please can any of you help me on this.

Thank you,
lokesh

Find more posts tagged with

Comments

Adam Stoller

What version of TeamSite, what platform?
What kind of backup procedure is in place - i.e. are you backing up /iwmnt (or Y:\) in addition to /iw-store ? (this is the most likely culprit because backup software tends to 'touch' the files they backup by altering some attribute on the file - though I believe this is mostly a Windows thing) - and that will cause all the files to show up as modified.

--fish
(Interwoven Senior Technical Consultant)

lokesh

Hi,

TS 5.5.2 on Solaris 8.0.

I am backing up /iw-store and /iw-home

Thank you,
lokesh.

Adam Stoller

So you're saying that there are a whole bunch of files that were submitted, not changed by anyone manually, but are now showing up as modified when you do a List Modified?

This is the first I've heard of this on Unix (as indicated, this is usually a backup thing on Windows) - and you're sure that /default and/or /iwmnt and/or /.iwmnt are not being backed up?

I don't have a Unix system to check on - but hopefully other folks out here will be able to chime in with either "seen that/did this" experiences or other ideas of what to look for.

--fish
(Interwoven Senior Technical Consultant)

lokesh

Hi,

I am in workarea EMS and went to View menu and did List Modified,then it gives me bunch of files which are modified in that workarea as root but they are not touched.

/iwmnt and /.iwmnt is not been backedup,we are having harbor as a backing agent from solaris. This is existing from long back from months.

Now recently we changed the backup agaent to BackupExec which the files will be backedup from solaris Teamsite Box to Windows backup machine.

Thank you,
lokesh.

Edited by lokesh on 02/12/03 09:42 AM (server time).

Adam Stoller

I'm not sure I understand what you're saying.

You were using one backup system - you're now using anothe backup system.

Did the problem ever occur with the old backup system?
Has the problem existed only *since* you switched to the new backup system?

Are you positive that noboy touched any of those files in the workarea? Do they all have the same (or almost the same) modification date/time-stamp? If so, is it recent (today, yesterday), old (last week/month), or anchient (last year)?

--fish
(Interwoven Senior Technical Consultant)

johnjamesmarsh

Hi,

Just thought I would resurrect this thread as we are now suffering the same problem.

We have a TS 5.5.2 system running on Solaris 8. We are using NetBackUp. When the backup runs all the files in all workareas have their inode modification time changed (found by using ls -lc). The mod inode mod time on all files is sequential in every workarea. This means they all show up as modified in Teamsite. If you try to submit the files Teamsite does nothing as the files are not different from the version in staging. If you ask Teamsite for a list of modified files it gives you all the files in the workarea (as their inode mod time is different).

Is there a setting in Teamsite to say ignore the inode mod time? The backup best practice seems to have no additional info on this. To make matters worse, we have a TS 4.5.1 system being backed up in the same way by the same team and it does not suffer from the same problems.

Any suggestions would be gratefully received.

John

taiyo

I've run into the same problem but as a result of changing permissions on directories via the windows explorer view.

I'm wondering if someone could provide a perl script to remedy the situation.

I thought that all that was needed was to create a regex that compares the Date Modified and File Size in TeamSite vs. STAGING. If these attributes are the same then "GET LATEST" from STAGING. However, I'm know seeing that modifying the directory permissions outside of TS increases the File Size by 1KB.

I still believe Perl should be able to handle this. Any thoughts?

Thanks,

taiyo

Adam Stoller

Changing permissions on a file modifies attributes associated with that file within TeamSite such that the file is considered modified - you would need to submit it again in order to get the modified attributes recorded in staging. If you are using TeamSite 5.5.2 or higher, you can periodically use the CLT iwfsshrink to eliminate duplications of identical content versions as a result of attribute modifications.

Backup software, especially on Windows, has a habit of touching the 'archive' attributes on files - If you are unable to turn off this behavior in the backup software - do *not* attempt to backup the Y:\ drive (which generally shouldn't be done anyway - but that's another topic).

I'm at a site now, using Unix, in which every night some process (believed, IMO, to be a backup process) touches all files that were modifed the day before - in some way (thus far not yet pinned down) that they are perceived as modified. I wrote some scripts (unfortunately they're on the customer's server right now - so I cannot post them from my laptop) that does an iwlistmod, followed by a loop using 'cmp' and if the files are the same - performs a forced iwupdate of the file in the workarea - coupled with another script that does almost the same thing, but performs an iwdiff first and lets you choose whether or not to force-update the file in the workarea. It's not ideal, but it lets us move forward on the things we're currently focused on rather than spending a lot of time trying to figure out what's happening every evening to cause the problem [this is on a Dev server, so it's not perceived as being critical ... yet]

--fish
(Interwoven Senior Technical Consultant)

taiyo

hey fish any chance your script will work on a windows box?

this is exactly what i need

-thanks e

Adam Stoller

Sigh - I forgot to copy it to my laptop today - maybe I'll remember tomorrow - but it really wasn't all that complex:
1) run iwlistmod for a given branch / workarea
2) parse the output (I looked for only entries that began with "f+")
3) run a comparison between the workarea and staging area for that file
-- On Unix, I tend to use the utility 'cmp' for this, but you could also probably use 'iwdiff -q'
4) if the files are identical - run iwupdate -s on the file (or maybe it was -w - can't remember)
5) for everything else - print out either that you are skipping it, or that it is different.

The wadiff script was similar (intended to be run after the above script) - but it would print out the name of the file, and then run iwdiff, and then print out the name of the file with a prompt asking if you wanted to forcibly update the file in the workarea from staging - if you said 'y' - then it did the iwupdate -s (or whatever)

I have noticed that there are some path/filenames for which the iwupdate failed - I think because of the need to quote or escape certain characters - but by in large these are the exceptions and once I get to that point I just do a List Modified in the GUI and select them turn Overwrite on and click Get Latest.

Again - this is a simple way to work-around the problem if you don't have time to focus on finding and fixing the cause.

I'll try to remember to retrieve my code tomorrow - but chances are I'll forget (I generally don't process DevNet while at my customer's site and thus things things slip from thought)

--fish
(Interwoven Senior Technical Consultant)

taiyo

So I've written a script that does work in the Windows environment. Pretty stoked that it's working properly on some of the lower level directories. I'm not sure if outside issues may be the cause of TeamSite going down when I run the script but I'm curious if there is any reason why this script would cause TS to crash?

thanks for all your help ---

see attached for the script i've used for the Win environ - taiyo

Edited by taiyo on 07/25/03 02:34 PM (server time).

Adam Stoller

I'm glad you've gotten it to work.

Some general critiques - (I haven't had a chance (and probably won't) to look at this in detail and see what it's doing but I don't think your script should be able to crash the TeamSite server process).
---------------
Include 'use strict;' in your code and '-w' at the end of the #! line -- it will help you clean up all sorts of things that might cause problems (and hours of headaches tracking down) later.

Since you're using TeamSite::Config::iwgethome() - you might as well use TeamSite::Config::iwgetmount() and get rid of the hard-corded "Y:"'s in your code.

You define $vpath [no 'my'] to the same value as $dev_path -- and the value you're giving it is *not* a vpath - but a filesystem path (vpath's begin with the archive name - like /default/... - filesystem paths begin with the mount-point like Y:/default/..., or /iwmnt/default/...)

You've got two lines opening the same file - (lines 18 & 20) - my guess is line 18 was intented to be removed?

Unless this is intended to be run within the scope of a workflow (where there have been some problems with redirection of output) - there's probably no need to use a temporary file for storing the data in, just to read it out again.

I've seen this construct:
if ($modfile =~ "f+")
before - but to the best of my recollection, you really should be using either:
if ($modfile =~ /f+/)
or
if ($modfile =~ m"f+")
If it works as written, I think that's more of good luck than good code - and you're better off switching to either using the default delimiters (//) or specifiying the delimiters by explicitly using the 'm' prefix (m|...|, m+...+, m!...!, etc.)

Likewise with your split() line - the first argument should be delimited with slashes [split(/****/, $string)] not quotes [split("****", $string)]
---------------

The above comments are not meant to reduce the value of the work you've done, but to help make your coding more robust, and syntactically easier to interpret by others who may try to read the code after you.

One of these days I'll remember to pull over my code for this (which is *not* a work-of-art - it too was thrown together quickly to do what I needed and not meant as a permanent fixture)

--fish
(Interwoven Senior Technical Consultant)