no confirm on windows ftp client

If you don't want to be bothered with answering whether you'd like to retrieve every single file you specify with mget, then start the FTP client using the ``-i'' argument, like so:

ftp -i 127.0.0.1

FileNet Image Manager BES_convert fails

When performing "initfnsw start", if you get:

2009/10/14 16:12:06.296 161,0,1008 BES_convert (2944.3060.20 0xb80.bf4) ... SSD(2944): Can't bind dn_len, size=2

2009/10/14 16:12:06.406 211,1,13 TM_daemon_ctl -f 344 -p 0x64c -c 0x1 (3072.2688.1 0xc00.a80) ... [SERIOUS] Exec of 'BES_convert' returned non-zero status of '0x3'.

2009/10/14 16:12:06.406 211,1,11 TM_daemon_ctl -f 344 -p 0x64c -c 0x1 (3072.2688.1 0xc00.a80) ... [SERIOUS] A failure occurred while waiting for a process to complete.

2009/10/14 16:12:06.406 211,1,13 TM_daemon_ctl -f 344 -p 0x64c -c 0x1 (3072.2688.1 0xc00.a80) ... [SERIOUS] Error (0xd301000d) encountered during initialization of IS software!

2009/10/14 16:12:06.406 211,1,11 TM_daemon_ctl -f 344 -p 0x64c -c 0x1 (3072.2688.1 0xc00.a80) ... [INFO] syslog semaphore has been re-established.

2009/10/14 16:12:06.406 211,1,11 TM_daemon_ctl -f 344 -p 0x64c -c 0x1 (3072.2688.1 0xc00.a80) ... [INFO] Software will now be shutdown due to previous error.

You can recover with:
fn_util initsec
initfnsw start

[info]

how to u/mount drives on windows command line

Creates, deletes, or lists a volume mount point.

MOUNTVOL [drive:]path VolumeName
MOUNTVOL [drive:]path /D
MOUNTVOL [drive:]path /L

path Specifies the existing NTFS directory where the mount
point will reside.
VolumeName Specifies the volume name that is the target of the mount
point.
/D Removes the volume mount point from the specified directory
/L Lists the mounted volume name for the specified directory.

FileNet Content Engine 3.5 - Verity Indexing Stopped

Here are some pointers regarding indexing and what to look for when comes to figuring out if there are problems.

1) Gather CE trace logs, specifically ContentSearch and ContentRM. Turn on all the trace options/flags for both of these logs.
You can view the ContentRM CE trace log and see the items being queued for indexing by looking for the phrase "sending filename to CBR indexer". If the indexing failed, you'll see "indexing failed, updating all requests".

You should see signs of indexing the ContentRM with a call to IndexIQFile, like this example below.
2005/07/27 22:31:33.418 0ed4 0000 -> CFN_Indexer::IndexIQFile 2005/07/27
22:31:33.418 0ed4 0000 C:\Program Files\FileNet\Content Engine\Log \IndexQueue\000000065{529A1CC0-7CB8-456D-B37D-51D05248E179}001000
{0C3C9546-8729-4DB3-A567-85DD4260E93A}.IQ

2) Verity SHOULD log errors to ContentSearch trace if there is a problem with indexing a specific item.

If a Verity Indexing submit request fails there will be an error in the event log 'An error occurred in a Verity VDK method call.' on the File Store Service computer. To get detailed info the best place to start is the ContentSearch trace, which will contain output from the Verity call-backs. Normally Verity (through the VDK, CS used K2) doesn't fail the submit request if files are missing, or can't be indexed - it logs it in the callbacks and returns success.

3) Check the sysinfo log (under the indexing folder in the file store
physical location, typically : C:\\
\index\fs0
Look for errors “unable to open” and UNC paths. Permissions errors can indicate that the user that is running the FSS may not have adequate permissions to the FileStore folder (see step 10).

4) Look in same folder : C:\\\index\fs0
“lock” files .lck. Believe that removing them from that folder may release the indexing mechanism if it was locked by Verity when it hit a previous error. I.e. Collection.lck

5) If nothing is being indexed, check the indexing folder “parts” folder for current entries (this is a bit more difficult if there are multiple indexes since you’ll have to check every one of them). Check that the files have recent date time stamps. If they are rather old and yet the system has been up for a while, the indexing isn’t running correctly.

6) If nothing is being indexed, look on the CE, there is a folder under the installation folder that holds items waiting to be indexed. If the CBR halts for any reason, ...\FileNet\Content Engine\Log\IndexQueue will begin to fill up with files. Once indexing resumes, the number of files in the folders should go back down until it reaches zero (then the indexing process will have caught up with the current system requests).

7) When is indexing completed? The number of files in...\FileNet\Content Engine\Log\IndexQueue will be zero and queue entries such as the following will appear in the ContentSearch CE trace log:

2005/06/10 01:04:13.632 05d4 0000 VdkCollectionSubmit AOK 2005/06/10 01:04:13.632 05d4 0000 VdkCollectionSubmit: \\3lfsusda\fn_fs \FS_FS2_upg\index\fs0 <656>

[Thanks Fintan]