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; } } }

OpenAPI

System

How can I change the "modification" indicator of a file to "unmodified" after I have updated it's extended attributes in the STAGING area. Basically, I am updating some values in the Teamsite metadata section of a file's extended attributes (properties), however, after I make the modifications I don't want the file modification flag set to indicate that the file has been modified.

Find more posts tagged with

Comments

Hemant

Staging area is supposed to be a read only thing. Then how can we ever we modify it?

JonathonG

Assuming you didn't mean you actually changed a file in STAGING, because that is impossible.

I'm pretty sure there is no way to set a file's "modified" flag to unmodified. I would say this is a good thing. In changing the extended attributes, you have modified the file, i.e. it is no longer the same as the file in STAGING. Thus, TeamSite alerts you that it is modified. If you were able to re-set the modified flag, you would set yourself up for unintentionally losing changes, as the next "Get Latest" would overwrite your file. Of course, if you don't want your changes anymore, you can always do a "Get Latest" with overwrite turned on. That will reset the modified flag, but will also lose your changes.

Jonathon
Independent Interwoven Contractor

Migrateduser

It actually is possible to change extended attributes in some buggy versions of TeamSite, but it is not a feature or something that should be used.

Adam Stoller

Correct - you can do it in 5.5.2 SP2b - and if you do, you're almost definitely corrupting your backing store - so just say "no" to changing EAs in STAGING ;-)

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

Migrateduser

of course it would be nice if the product would "just say no" before corrupting your backing store.

Adam Stoller

I agree - I think they did fix this in one of the SP's that followed SP2b - I just don't know if it was in SP3 or SP4 (at least I believe they fixed it)

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

Migrateduser

Again I'm just going to throw this out - they should really test the product more before doing releases. It seems kindof nuts that there even is an SP4 - I think that means there were a lot of bugs in 5.5.2 (and that's after 5.5.1 which was never recommended for production and 5.5.0 which was never even released). People shouldn't be finding bugs that can corrupt a backing store in a production release - that makes us all beta testers. And we've all been bitten by Interwoven patches that made things worse. Not to mention that in many environments it is hard to get resources to do the testing to certify a patch even if there are no serious bugs in it, or at least no bugs other than these ones that normal customer testing would probably never identify.

I am certain I have seen hundreds of bugs in TeamSite. When you factor in Templating, OpenDeploy, DataDeploy, etc. there have probably been thousands of bugs released. I understand for something that supports several platforms, application servers, etc. but for something that only runs in a few environments it is hard to understand/accept.

JonathonG

I think you can thank Microsoft for this. I have had quoted to me a number of times that, "that's the way Microsoft does it." as if that makes it right. From a business standpoint, Microsoft is doing very well, so that makes it hard for engineering/QA to make any point about customers wanting bug-free products. Its sad, really, and the engineer in me cringes at the slopiness of "released" code in the software industry as a whole (IWOV no exception).

Jonathon
Independent Interwoven Contractor

Migrateduser

Microsoft is obviously a good example of a marketing company. I wouldn't model a software development company after them.

JonathonG

Neither would I, but many fail to make the distinction you make. Thus, many software companies *are* modeled after them. And, from a pure business standpoint, it appears that most software consumers (individual or corporate) have bought into the idea that software will always be buggy, so just deal with it. *sigh*

Jonathon
Independent Interwoven Contractor

Collector.dcpackage

Adam Stoller

Microsoft definitely is an extreme case - but Solaris, HP-UX, AIX, Linux, Macos all have patches and service packs as do products like Oracle.

As much as I'd love to see more bugs fixed in Interwoven products *before* they're released - I realize they're dealing with moving targets on the OS-end and it saps most of the QA time just trying to figure out which combination of software versions they're going to test things against.

So - given a choice between supporting a wide-array of environments with a moderate degree of stability and supporting a narrow-array of environments with a hige degree of stability - which would *you* choose - as a consumer? if you were the vendor?

Personally, the issue with the modifiable backing store doesn't bother me as much as other, less obscure / more basic, bugs do. But as company's in general (and IWOV is not an exception) tend to be driven by "market" - I suspect they will continue to produce more varied and newer versions of the products they have and not take as much time for doing things like hardcore cleanup of all those little, non-critical, but highly annoying bugs (like making sure all the CLTs accept '-h' and '-v' and exit with the correct [and in many cases distinct] status value under all circumstances) - I have a feeling that most of the Engineers wouldn't mind taking some time to do that - but I don't think they have the option/time to do it.

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com