Introduction:

wcRefresh is a wcBASIC WCX application designed to refresh (add/remove/update) the file database storage areas associated with the current logged on session. By refresh, we mean synchronized the Wildcat! files database records with the physical files stored in the file areas storage locations.

By default, when starting wcRefresh, it will perform a two phase scan:

Phase #1 - VERIFY/UPDATE

During the Verify/Update phase, each file record is checked for a matching  physical file associated with the file record. 

If the physical file exist, then its file record time, date and size is updated.  This file information update may be skipped by using the /keepinfo switch.  

If the physical file does not exist, the file record is deleted from the database only if is not marked offline.  If the file is already marked offline, the /purgeoffline switch can be use to delete the record.  If not offline, the /markoffline switch can be use to mark the file record offline.

Phase #2 - ADD

During the Add phase, each physical file in the file area storage locations are checked against the database to see if a file record exist. If no file record exist, then a new file record is added to the database.  The new file record will be given a description of "system address file" with the uploader name of "system".  This may be changed with the /desc and /uname switches.

wcRefresh requires no command line options to run.  It will automatically perform both scans and apply the default verify, update, delete, add logic.   You may change the default logic by using the optional command line options shown below.

Why and When is wcRefresh useful?

Wildcat! offers a secured virtual file library and database system.  The database holds extra information about the file and it controls the integrity and security of the system.   Each uploaded or added file to the database is recorded, thus a physical file without a record is unknown to Wildcat!

WcRefresh is useful for Wildcat! operators who are bypassing the normal upload and download methods or the Wildcat! File I/O management methods and are using external copying, deleted, moving of files in/out of the file storage areas.  When this is done, the Wildcat! File Database records remain unchanged and are out of synch with the physical files in the file areas.

If you place a file in a Wildcat! File Area storage directory using methods such as using Windows Explorer, DOS copy/move/erase commands  or with a backend server,  Wildcat! will not see these unrecorded file "uploads", hence users will not see the files in the file areas.  Conversely, if you manually delete a file which was recorded in the database, Wildcat! will continue to think there is a physical file because the record still exist.   Hence, users will see the file listed, but will fail in downloading the file.  

In practice, this is very common situation.  Many customers use integrated but independent backend data processing servers to watch directories and process new user uploads. When the backend process has completed processing the new file, in many cases it will delete the file.  In many cases, the backend process may even place new files such as upload confirmation response files for the user to download during the current or next logon session.  In all cases, the non-wildcat deletion and addition of files in the file areas are not recorded in the database, and the database is out of sync with the actual physical files in the file areas.

The dynamic and proper solution is for all client interfaces to Wildcat! Server to use the WCSDK  AddFileRec and DeleteFileRec() functions to directly access the server database.   However, the WCSDK requires a programming staff, and for many customers who do not have the programming skills or resources to accomplish this task, the WcRefresh utility can be used to rescan the file area folders and synchronize the file database.

When the database is out of sync, over time system degradation will be experienced. This is especially true for systems with high rates of uploads and downloads. So even if dynamic file availability for users is not a requirement, the database should be refreshed with wcRefresh or repaired with WcRepair on a regular maintenance basis.

What file areas are scanned?

The file areas scanned by wcRefresh depends on who runs it and from where (local mode, ftp or web)

If wcRefresh is started when the user is not logged, then the internal system account is used for access and all areas are scanned. This is typically the case when starting wcRefresh with the wcRUN utility from a DOS shell or from an event scheduler.

If wcRefresh is started within an authorized user session, then only the file areas the current user has access to will be scanned.  This is typically the case when starting wcRefresh from dialup, Telnet, Web or FTP. Since many implementations of Wildcat! is to hold single exclusive (private) file upload/download area for each user, running wcRefresh in user mode is ideal for updating the user's "private folder" and no one elses.

See the "How To" methods.

Special Notes About Using wcRefresh

The following notes are provided to give you some insight about using wcRefresh:

• Reduce Database I/O Redundancy and Overhead:
  
  When using wcRefresh in local mode with wcRUN or with a regular scheduled event, keep in mind, running in local mode will scan all the file areas.  Setups with many file areas should not run wcRefresh at a high frequency as it will be wasteful and could degrade the system performance.
  
  However, it should be run atleast one per month or some low frequency regular pre-determined schedule to serve as a "overall cleanup". i.e., one per day, per week, per month.  See the Pack/Repair note:
• Pack/Repair the Database:
  
  Wildcat! uses an internal database system where deleted records are not removed, but marked deleted and reused for new file records.   If you have a high upload/download (add/delete) frequency, eventually, the database will need to be repacked.
  
  On some monthly, quarter or backup scheduled maintenance event,  you should shutdown the server and run wcRepair to pack and reindex the database.  Running wcRepair on a regular basis, and this might include defrag the hard drive, will drastically improve the server database performance.
• Use Login Session Refreshing:
  
  If you have an operation for secured one user/one file area operation, consider using the logon hook method (discussed below) to minimize the scanning to specific file areas) belonging to current logged on user only.
• Use Wildcat! API Client/Server Database Management:
  
  Ideally, customers who seek high performance, high scalability dynamic availability of new files, should seek using Wildcat! Server API database I/O framework.  Customers who have a programming staff can use the Wildcat! Software Development Kit (WCSDK) which offer Wildcat! client/server development support for all major languages, including:
  
  Microsoft C/C++, 
  Microsoft .Net, 
  Microsoft C#, 
  Delphi Pascal, 
  Visual BASIC,
  Sun Java, 
  PHP, 
  including WCBASIC.

Optional Command Line Parameters

You may change the default scanning logic by using the following command lines options:

How To Use WcRefresh:

WcRrefesh can be started under two basic modes:

• Non-User session mode (wcRefresh will use the internal system account)
• User Session Mode (user is authenticated/logged in)

Non-user session mode is when wcRUN is used.  When using wcRUN, weRefresh with login as the internal system account which has secured access to all file areas thus all file areas will be scanned for refreshing.  

User session mode is when wcRefresh is started during under Dialup, Telnet, WcWEB or WCFTP user session.  When wcRefresh is started under a logged in user session, only the file areas the current user has access to will be scanned.

Running wcRefresh with wcRun, wcEvent,  Batch file or Command-line:

If wcRefresh is executed with WCRUN, manually within an wcEvent or batch file, it will login as the "system" to perform a global file area wcrefresh:

Examples: 

wcrun -r wcrefresh /auto
wcrun -r wcrefresh /auto /areas 42 43 100
wcrun -r wcrefresh /auto /addonly
wcrun -r wcrefresh /auto /quiet /groups 1 2 3

Running wcRefresh in Dialup/Telnet Mode:

After a user logs in and after the personal mail is checked, WINSERVER will look for LOGON-*.WCX files to execute and run each one. If any, they will be stored in the \WC6 directory.   

Simply copy the wcrefresh.wcx to the next LOGON-x.WCX file in sequence.

For example, if you have 3 of these files, then your next one is 4. If you have none, then your first one will be LOGON-1.WCX.

Alternative recommended auto logon hook method:

The above LOGON-x.wcx method is the old way of running logon wcx applications when the user logs in.  The new way is to put the WCX file names in a special file called CONFIG\LOGON-HOOKS.TXT.  

For example, adding theses lines to this special file CONFIG\LOGON-HOOKS.TXT:

#Run WCREFRESH in auto and quiet mode
wcrefresh, /auto /quiet

will automatically run this wcx when the user logs in.  

This new method is preferred over the old method because you can better control the sequence, you can add comments to the file, and you don't have to rename them to LOGON-#.wcx

Running wcRefresh in wcWeb Mode:

In WEB mode, WcRefresh will only run with authenticated web sessions (user must be logged in).  The Wildcat! Web Server (wcWEB) naturally supports the running of WCX applications, hence WCREFRESH.WCX can be started as a HTTP request using the link URL:

/code/wcrefresh.wcx

However,  wcWEB will restrict running WCX programs using an URL if the WCX does not have a "html-" prefix or it's file name is not listed in the data\wcxaccess-custom.lst file.

You may use the html- prefix method by copying wcrefresh.wcx to create a 2nd html-wcrefresh.wcx and then use the link URL:

/code/html-wcrefresh.wcx

For security reasons, we highly recommend to use the WCX ACCESS control method as this will provide more control over who is allowed to run WCREFRESH.WCX from the web.  This will also not require you to have a 2nd copy of the same WCX with the html- prefix. 

Another way to run wcRefresh.wcx from wcWEB is to use a WCT macro RUNWCX command in a web page with a .WCT extension:

@RUNWCX WCREFRESH /AUTO /QUIET@

A good place to place this WCT macro command is in the HTTP\DEFAULT.WCT  private home web page.  Once the user logs in, it will automatically refresh his private file areas.

TIP:  

Create a WCT web page call "http\RefreshFileAreas.wct" and place the above RUNWCX command in this file. This will allow you to use this WCT web page as a link url:

<a href="/RefreshFileAreas.wct">Refresh</a>

You may also include the RefreshFileAreas.wct with a WCT INCLUDE command in any WCT web page:

@INCLUDE "wc:\http\RefreshFileAreas.wct"@

Running wcRefresh in wcFTP Mode:

To use wcRefresh in FTP mode when users login, a FTP WCX event hook called FTPLOGON.WCC needs to be created with the following lines:

-----------  CUT HERE --------------
PrintDeviceEnabled(FALSE)
Run("wcfresh.wcx","/auto")
GlobalResult = FALSE
-----------  CUT HERE --------------

Compile it to create a FTPLOGON.WCX file.   

Important notes about running a Wildcat! FTP wcx event hook:

• The FTP LOGON event hook must always set GlobalResult = FALSE, otherwise the wcFTP server will deny the ftp user logon.
• All FTP wcx event hooks must run in passive mode (quiet, do not PRINT anything).  If not passive, then this may confused the FTP client/server session with unknown commands or sequences.

Running wcRefresh in Sysop Menu:

Administrators can add a menu hook to the sysop menu to run this program. Since the sysop is a "logged in" user, the program will wcrefresh all file areas the sysop has access to. 

Use WCMENU to add a run WCCODE (WCX) program menu option to the sysop menu.

Skipping Files

When scanning the file areas for new files to add to the database, wcREFRESH will check for a special skip list file called:

DATA\WCREFRESH-SKIPLIST.TXT

If this skip list file exist, then it will be checked to see if the file to be added should be skipped.  Each line read represents a specific file or file specification to skip during the add new record phase.

If the skip list file does not exist, then wcRefresh will use an internal skip list with two file entries   "wc:\files\areas(*)\wccreate.dir" and "wc:\files\areas(*)\.wctaccess"

wccreate.dir are dummy files created by the Wildcat! CD installer.  These "wccreate.dir" files are not required and can be deleted. .wctaccess are directory access files specifically understood by wcWeb. Some setups may have public symbolic links to Wildcat! file area directory locations.