Discussions
Categories
Groups
Community Home
Categories
INTERNAL ENABLEMENT
POPULAR
PUBLIC CLOUD
PRIVATE CLOUD
Quick Links
MY LINKS
HELPFUL TIPS
Back to website
Home
Web CMS (TeamSite)
scf_CreateEA failed...
mmb
Hi
TS 5.5.2 Solaris
using iwcp to take a copy of a file, we are getting alot of the following errors spat out in to the iwtrace.log
[Mon Nov 1 12:01:31 2004] Error, scf_CreateEA failed, err = 17
[Mon Nov 1 12:01:31 2004] Error, scf_CreateEA failed, err = 17
[Mon Nov 1 12:01:31 2004] Error, scf_CreateEA failed, err = 17
[Mon Nov 1 12:01:31 2004] Error, scf_CreateEA failed, err = 17
[Mon Nov 1 12:01:31 2004] Error, scf_CreateEA failed, err = 17
[Mon Nov 1 12:01:31 2004] Error, scf_CreateEA failed, err = 17
The copy seems to work, but we were wondering if anyone has seen this error before & if it is worth worrying about?
thanks
- mark
Find more posts tagged with
Comments
nipper
Are there EAs on the source ? How about the destination ?
Andy
Adam Stoller
What's the actual command (with arguments) being used?
Is the target file one that *used* to exist?
--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com
mmb
Thanks for the replies (Nipper & Ghoti),
The scenario is this:
A developer is writing a script that is going to run an archiving process within a branch, in order to produce a page of old promotions.
At some point he takes a copy of a STAGING version of a file, with EAs associated, and uses iwcp to make a copy of that file in the workarea, but with a slighty different vpath
e.g. /default/main/branch1/STAGING/promos/promo1.html is copied to /default/main/branch1/WORKAREA/workarea1/promos/archive/promo1.html
It is at this point that the iwtrace.log is updated with a load of the scf_CreateEA failed.. errors.
The exact syntax of the command is
system("${iwhome}/bin/iwcp $filepath $new_filearea >/dev/null 2>&1");
Where $filepath is a STAGING vpath and $new_filearea is the new vpath in a workarea.
You may be onto something with the idea that the file has already existed in the workarea, but with a different vpath...
thanks in advance for any advice,
- mark
Adam Stoller
Perhaps this data, from a case I opened for my customer, will help...:
ENVIRONMENTTeamSite 5.5.2SP2b + patches
Solaris 8BACKGROUNDCustom CGI script being use to perform administrative renames and moves of files within TeamSIte (taking care of renaming DCRs, regenerating pages, submitting the deletion of the old files and the creation of the newly named files, deploying those changes to their web server, etc.).
The CGI script uses iwcp - and [unfortunately] is currently written to use vpaths as arguments like:
iwcp /default/main/.../WORKAREA/waname/folder1/file1 /default/main/.../WORKAREA/waname/folder2/file2
[a previous case] dealt, at least in part, with an issue that seemed to come about if you performed the commands as such:
iwcp /default/main/.../WORKAREA/waname/folder1/file1 /default/main/.../WORKAREA/waname/folder2/file2
iwcp /default/main/.../WORKAREA/waname/folder2/file2 /default/main/.../WORKAREA/waname/folder1/file1
i.e., copying the file, and then copying it back -- would result in "ERROR:02439: Operation not permitted"
The recommendation (which hasn't been done yet, also unfortunately) was to use an explicit file system path:
iwcp /iwmnt/default/main/.../WORKAREA/waname/folder1/file1 /iwmnt/default/main/.../WORKAREA/waname/folder2/file2 iwcp /iwmnt/default/main/.../WORKAREA/waname/folder2/file2 /iwmnt/default/main/.../WORKAREA/waname/folder1/file1
This [supposedly] works.CURRENT SITUATIONThe current problem is that while the CGI hasn't been "fixed" to use the /iwmnt prefix for the arguments, it has appeared to work fine in 99% of the cases (where we did not try to copy the file back into place) - in the 1% [known] cases where it doesn't work the result is as follows:
/.iwmnt/default/.../file2 exists, you can do an ls -l on it, no problem
/iwmnt/default/.../file2 only partially exists.
In the second case - if I cd to that directory and type /bin/ls - I'll see "file2" show up, but if I type /bin/ls -l - I'll get an error saying "./file2: no such file or directory"
iwstat -c does not show any "dirty" points - there doesn't appear to be anything waiting to be flushed to cache.
ISSUE #1: How do we "fix" this un-synchronization between the non-caching and caching mount points?
ISSUE #2: If iwcp cannot handle file system paths (by virtual of the /default symlink) that are really vpaths - it should not allow the operation to go through
ISSUE #3: A bug needs to be entered against the IFS - one should not be able to create this kind of discrepancy between the caching and non-caching mount points.
I may try a few things tonight to see if I can figure out the answer to #1 - but I'd like to get some Engineering input.
Entered By: Support 1/2/2004 7:34:52 AM
Bug has been filed - #50319
Entered By: Support 9/27/2004 12:44:09 PM
Suggested to use the iwfreeze +0 to clear the cache prior to iwcp. If the CLT really starts doing the synchronization, it will strain on the resources.
I have not had the opportunity to try this out since then - been working on many other things and for one reason or another this hasn't caused us a lot of problems since then (
might be due to nobody using that custom menu item...
)
--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com
mmb
yep, that looks like similar behaviour.
I think that we will test this thoroughly and see what effect if any the error messages cause.
We are going to upgrade to TS6.1 sp1 soon, so hopefully this will be resolved then...(?!)
thanks for your time
- mark
