Windows File System Errors

Created: 15 January 2009. Last Reviewed: 22 April 2009

Disk Corruption

One of the main reasons for Database corruption in Enabler is the underlying Hard Disk and/or Windows File System becoming corrupt. This can happen for numerous reasons including physical hardware failure or virus activity.

Often, problems can be resolved by running a Check Disk command over the drive that Enabler is installed on as follows:

Open a command prompt

Click Start → Click Run → type CMD → Click OK

At the command prompt, type the following:

C:\> CHKDSK X: /F

(Where X is the drive letter that you would like to scan, most commonly C:)

If there are files in use that cannot be scanned, such as core Windows system files, you will be prompted to run the Check Disk at the next reboot. Answer Y to this.

When the machine is rebooted, the Check Disk will scan for and repair any hardware or file system issues.

Disk Fragmentation

One of the reasons for a computer slowing down is that the Windows File System becomes fragmented. Poor performance arises when the files that are held on the Hard Drive are broken up and written to different parts of the disk, resulting in the Hard Drive doing a lot more work than should be needed to open the files.

Because Enabler databases are constantly being updated, they are easliy affected by Disk Fragmentation which can often affect the performance of database intensive processes like Host Imports and reporting.

A basic Disk Defragmentation application exists in Windows and can be found here:

Click Start → Click All Programs → Click Accessories → Click System Tools → Click Disk Defragmenter

You can use this application to analyse the disk to see how fragmented it is, and you can then proceed to defragment the drive if it is needed.

Note: It is strongly recommended that all Enabler apps are closed before running a Defragment so you avoid Database errors when the database files are defragmented.

To assist with more timely discovery of disk subsystem problems, from Enabler 4.46, a new option has been added to run a disk maintenance batch file as part of the End Of Day functions. This is described in detail below.

Disk Maintenance Batch File – From Enabler 4.46

A new option has been added to the Communications Setup screen – “Disk maintenance batch file”

This field is only available when “Restart Nibbler During EOD” is turned on and allows you to enter the <path>\<filename> to an external command file that will be run when nibbler restarts during the EOD.

Eg: \\eee-server\shared folder\batchfile.cmd. If this field is left blank, nothing will be run, otherwise the command file will be executed and once completed, Nibbler will be restarted.

The purpose of this file being run is really so that various disk maintenance functions can be run. This largely replaces the disk maintenance as part of purge and backup - which since Windows 95/98 hasn't really done anything other than reindex anyway!

There are two disk / file system problems that occur regularly in stores (and even HO server) which are the enemy of Enabler:

1. File system corruption (which is resolved by chkdsk /f). This will occur frequently in retail stores because the machines get a hard life, staff switching them off etc.

2. File system fragmentation. The small incremental growth that occurs in Enabler database and MDX files makes Enabler machines susceptible to extreme file fragmentation, and this severely impedes performance. This is NOT a flaw in Enabler, it is just a characteristic of the environment.

This is a very simple mechanism to assist customers in eliminating these issues. This is a simple approach, there are plenty of 3rd party tools out there that customers could use instead including sophisticated network administration tools etc etc. This technique makes use of features already in the O/S.

An example command file would be something like the one below. It has the ability to send email alerts to head office; it relies on the command line mailer bmail.exe which is freely downloadable to do this. http://www.beyondlogic.org/solutions/cmdlinemail/cmdlinemail.htm

--start sample

@echo off

set smtpserver=192.168.1.1

set smtpsender=diskalert@companyname.com.au

set smtprecipient=diskmonitor@companyname.com.au

chkdsk c:

if not errorlevel 3 goto DoDefrag

echo Y|chkdsk c: /f

bmail -s %smtpserver% -t %smtprecipient% -f %smtpsender% -a "File System Corruption Found" -b "Found file system corruption on %computername% C:"

goto endd

DoDefrag

defrag c:

endd

The three SET lines near the top most definitely need to be customised: the SMTP server address needs to be the customer's mail server, the sender address can be any address within the customer's domain, and the recipient address would be the person at the customer's head office who should receive the alerts.

The next step is a read-only chkdsk. If errors are found it schedules a chkdsk /f at the next reboot and sends a simple alert email. If there are no errors it does a defrag.

The above will work on Windows XP. It probably won't work on Vista unless UAC is disabled. It should also work on Windows 2003 server. Not sure about Windows 2000, but customer's with Windows 2000 could easily enough customise the batch file to their requirements.

Other customisations may be required: Enabler might not be on C: - in which case chkdsk and defrag need to be changed to operate on the appropriate drive. If Enabler is NOT on the Windows system drive, then the chkdsk /f can probably run immediately rather than during a reboot. Customers might wish to chkdsk and defrag more than just 1 drive. Customers might want to include an automatic reboot after the chkdsk /f, this would be highly dependent on each environment

Note: This batch file is a SAMPLE ONLY - customers must adjust to their needs, or seek chargeable support from us to assist them if required.

Note - the first night this process is run it WILL take a long time as the file system is likely to be highly fragmented. Thereafter it will run much more quickly as the defrag won't have as much work to do each night.

For many clients I anticipate they would put the batch file on the HO or EEE server and configure Enabler to run something like [/%5C%5Ceee-server%5Cshared%20folder%5Cbatchfile.cmd \\eee-server\shared folder\batchfile.cmd] (or whatever). Thus there is no manual rollout of the batch file. Stores MUST have ONLY read-only access to this share/directory/file as it would otherwise give a malicious store staff member unlimited ability to destroy all tills in all stores overnight!!!! Customer's with differing store environments can include multiple batch files in the directory at HO and use global config to configure each branch to run the appropriate version of the batch file. Clever customers will exploit this in all manner of different ways - this batch file is an opportunity to copy other files, patches, reports, you-name-it from HO to stores, run other processes in stores... the possibilities are almost unlimited. (The world is their oyster…J)

Customers could also use this batch file to self-replicate it locally to stores - after the first night or two they could change the E configuration to run the store local copy rather than download form HO every time - but the file is so small that running from HO shouldn't matter.

Customers without WAN/VPN - up to them to deploy the batch file to stores - could be achieved with tweaks to FTP scripts or ISLBatch or manually

See Also