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.
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.
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.
The following notes are provided to give you some insight about using wcRefresh:
You may change the default scanning logic by using the following command lines options:
|/nolog||Disable Logging. By default, when run in a user session, wcrefresh will log information to the current node ACTIVITY.# log file. If no user is logged in, then the log file is WCREFRESH.LOG|
|/verifyonly||Verify/Update file records only. Do not add files.|
|/addonly||Add new file records only. Do not verify/update|
|/areas # #, #-#||File areas to refresh. Space or comma delimited, ranges are supported with dash, i.e., 50-100.|
|/groups # #, #-#||File areas to refresh associated with the file group # number(s). If no /groups, then file group #0 (all file areas) are considered for the scan limited by those specified in /areas.|
|/quiet||No screen output|
|/desc "xxx"||Description used for the new file records added. The default description is "system added file"|
|/uname "name"||Name of uploader to use for the file record. Default is "system"|
|/markoffline||Verify File Record Phase: if the physical file does not exist, the file record is marked offline instead of deleting the record.|
|/purgeoffline||Verify File Record Phase: if the physical file does not exist and the file record is marked offline, the file record is deleted.|
|/keepinfo||Do not update the time, date and size of file.|
|/test||Check areas but will not update/delete records.|
|/addhidden||enable adding hidden files|
|/addsystem||enable adding system files|
WcRrefesh can be started under two basic modes:
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:
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:
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:
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.
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:
You may also include the RefreshFileAreas.wct with a WCT INCLUDE command in any WCT web page:
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 --------------
GlobalResult = FALSE
----------- CUT HERE --------------
Compile it to create a FTPLOGON.WCX file.
Important notes about running a Wildcat! FTP wcx event hook:
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.
When scanning the file areas for new files to add to the database, wcREFRESH will check for a special skip list file called:
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.