Discussions
Categories
Groups
Community Home
Categories
INTERNAL ENABLEMENT
POPULAR
THRUST SERVICES & TOOLS
CLOUD EDITIONS
Quick Links
MY LINKS
HELPFUL TIPS
Back to website
Home
Web CMS (TeamSite)
Very active user community
Bowker
We have a very active user community and have run into an interesting issue that I have to believe long time LSCS users must have run into.
LSCS Deployment error: IWDirent::Mkdir failed, err=31
The folder .../interwoven/LSCSRT-Store/ contains (what I believe) is a folder for every deployment pushed to LSCS. Try this: ll | wc -l (lowercase of LL | WC -L) in that folder. If you get to 32000 folders,deployments fail since (in the linux world) you can't have more than 32k links in a folder.
The solution is PAINFUL.
1) delete all the folders (all 32000 of them)
2) drop your LSCS database tables
3) recreate the LSCS tables
4) redeploy ALL your content/pages
This is really painful since when you deploy using PLC everything get's the modified flag set.
Has anyone else run into this?
Find more posts tagged with
Comments
Rick Poulin
Has anyone else run into this?
Yep, known issue. In TS 7.3.x, they implemented a fix so that there's a more nested folder structure for the deployed contexts. There's still a hard limit, but it's more like 4 billion instead of 32k.
Bowker
Fantastic!
nipper
Doesn't the 721 patch take care of this as well ?
Adam Stoller
Doesn't the 721 patch take care of this as well ?
Yes - 7.2.1 P1 fixed this - but you had to make sure that you applied the patch on both the authoring (TS) and targeting (LSCS / LSDS) side - carefully - as there were a number of steps that if not followed would land you in an indeterminate state requiring you to go through a whole bunch of manual procedures to fix (although by now, Support should be able to walk you through them fairly quickly)
Bowker
Thanks all for your comments.
With errors comes wisdom. Did you know that if you try to access content through LSCS you don't need to specify the project name? I mention this because we have never added the project= attribute to the request and it has always worked.
Now - what we learned.... If you don't specify the project= parameter LSCS assumes you want to use the "default" project. The default project is defined as the first project defined in the dbo.project table (lscsrt database). So when we blew away our database and redeployed everything, someone deployed a single piece of content from a small, secondary branch. That became the default project and none of our
http://(server)/lscs/v1/path/templatedata/
... queries were working. Deleting the secondary project from LSCS moved our main sites up to the first position and all works as normal.
Just thought I would let you know.