Corrupt File, Corrupt Workarea

When was the last time you ran iwfsck on your backing store?
Perhaps now would be a good time....

General recommendation: run iwfsck -d, redirecting the output of STDOUT & STDERR to a log file, at least once a quarter, preferably once a month, and if possible once a week - the sooner you discover a problem with the backing store, the easier / more likely it will be to get it fixed.

When was the last time you ran iwfsck on your backing store?
Perhaps now would be a good time....

General recommendation: run iwfsck -d, redirecting the output of STDOUT & STDERR to a log file, at least once a quarter, preferably once a month, and if possible once a week - the sooner you discover a problem with the backing store, the easier / more likely it will be to get it fixed.

We ran it yesterday and it didnot show any errors specific to the problem workarea.

Migrateduser

Have you opened up a support case?

We ran it yesterday and it didnot show any errors specific to the problem workarea.

You should consider opening a case with Support, they'll probably have you run iwfsck again, but with different flags.

Have you opened up a support case?

Yes, Opened it yesterday Morning with high priority since our users are not able to submit workflows or edit the file. They have not gotten back to me yet even after calling them again to explain them the urgency. I attached iwfsck log with the case.

Can you create a new workarea and see if the files are corrupt or not ? Maybe delete the old workarea and use a new one ?

Can you create a new workarea and see if the files are corrupt or not ? Maybe delete the old workarea and use a new one ?

Did that, File was fine in the new workarea, then once old workarea deleted and the new one renamed to the old workarea same problem appeared.

Try reverting to a previous version of the file. Edit it and see if it is corrupt.

I have had cases where files became empty, so I would revert and then reapply the changes.

Try reverting to a previous version of the file. Edit it and see if it is corrupt.

I have had cases where files became empty, so I would revert and then reapply the changes.

Done that too, reverted to many previous versions, edited, submitted, etc etc, Also tried to just import a standalone file with the same name and tried to apply extended attributes using CLT, Same result everytime, Somewhere there's a disconnet where the file's extended attributes stored. Support is not in sight yet.

Did that, File was fine in the new workarea, then once old workarea deleted and the new one renamed to the old workarea same problem appeared.

This begs a question: What is the name of the workarea in which the problem is occurring?
If you rename the problematic workarea, do your file operations work correctly in the renamed workarea?

This begs a question: What is the name of the workarea in which the problem is occurring?

funny, I called it I_hate_TeamSite and everything broke. I have no idea why.... Smiley Very Happy

Seriously, how long is the overall path ? I have seen issues when everything is too long.

lhdavis

To expand on the issue Sandeep described, we have a standard naming convention for our workareas, cityname_(internet|intranet), replacing (cityname) with the city's name. For this particular page as it's a system homepage (index.asp) that generates several files used throughout the site. We have workflow and formspublished code dependant on the workarea name and this page name.

When we create a new workarea with a different name, all is well and good and the extended attributes reappear on the index.asp page.

When we rename the file in the existing workarea, all is well and good and the extended attributes reappear on the index.asp page.

But if we change the new workarea name to match the standard naming convention or the homepage back to index.asp, the extended attributes disappear.

So our backing store has issue with that particular path for the (cityname)_intranet/(cityname)/index.asp file (although iwfsck did not list anything out).

To expand on the issue Sandeep described, we have a standard naming convention for our workareas, cityname_(internet|intranet), replacing (cityname) with the city's name. For this particular page as it's a system homepage (index.asp) that generates several files used throughout the site. We have workflow and formspublished code dependant on the workarea name and this page name.

When we create a new workarea with a different name, all is well and good and the extended attributes reappear on the index.asp page.

When we rename the file in the existing workarea, all is well and good and the extended attributes reappear on the index.asp page.

But if we change the new workarea name to match the standard naming convention or the homepage back to index.asp, the extended attributes disappear.

So our backing store has issue with that particular path for the (cityname)_intranet/(cityname)/index.asp file (although iwfsck did not list anything out).

That's all well and good - but you neglected to actually provide the information that was asked for - which is the name of the problematic workarea, which might provide fodder for us to try and help you.

Also - keep pinging support for assistance - because this is the kind of thing that they should be helping you with (and if it gets resolved through their help, please update this thread with the relevant information).

Yea I would thing the exact path of the asset will also be helpful, branch name(s), workarea name and folder/path.

Also I do not know that anyone asked about logs, anything in iwtrace.log ? Others ?

lhdavis

Sorry, since the internet branch/workarea is fine and we have longer branch/workarea names, I did not think it was important.

Here is the problematic branch/workarea/filename:
/default/main/VA/PITTSBURGH/INTRANET/WORKAREA/pittsburgh_intranet/PITTSBURGH/index.asp

These work fine:
/default/main/VA/PITTSBURGH/INTRANET/WORKAREA/test_pittsburgh_intranet/PITTSBURGH/index.asp
And
/default/main/VA/PITTSBURGH/INTRANET/WORKAREA/pittsburgh_intranet/PITTSBURGH/indextest.asp

But we are dependant on the workarea name being pittsburgh_intranet and the filename being index.asp

Also note that /default/main/VA/PITTSBURGH/INTERNET/WORKAREA/pittsburgh_internet/PITTSBURGH/index.asp works fine.

Any and all suggestions are appreciated.

Sorry, since the internet branch/workarea is fine and we have longer branch/workarea names, I did not think it was important.

Here is the problematic branch/workarea/filename:
/default/main/VA/PITTSBURGH/INTRANET/WORKAREA/pittsburgh_intranet/PITTSBURGH/index.asp

Note that /default/main/VA/PITTSBURGH/INTERNET/WORKAREA/pittsburgh_internet/PITTSBURGH/index.asp works fine.

Any and all suggestions are appreciated.

I assume VA means something like Veterans Affairs or some such - and not the state abbreviation for Virginia, since there are a number of "Pittsburg"s in the country, but only one Pittsburgh (with an 'h' on the end of it) - which is in Pennsylvania (PA).

However, based on the above, I would agree that the naming of the workarea would seem to not be a factor here, nor the length of the vpath.

I think Nipper's idea to check through the log files, and mine to keep pinging Support - are the two things to concentrate on now. This is such an odd [sounding] issue that I don't know that any of us (who are not on-site, do not have access to the servers) could do much more for you.

I assume VA means something like Veterans Affairs or some such - and not the state abbreviation for Virginia, since there are a number of "Pittsburg"s in the country, but only one Pittsburgh (with an 'h' on the end of it) - which is in Pennsylvania (PA).

However, based on the above, I would agree that the naming of the workarea would seem to not be a factor here, nor the length of the vpath.

I think Nipper's idea to check through the log files, and mine to keep pinging Support - are the two things to concentrate on now. This is such an odd [sounding] issue that I don't know that any of us (who are not on-site, do not have access to the servers) could do much more for you.

VA is veterens' affairs, I have been contacting support and they dont think this is important enough to be expedited. Hopefully they will get back to us today.