Joelle,

I've run into this also.  I had even opened a problem with IBM for
suggestions on how to circumvent the corrupt file.  I did not have any
success.  We always had to wait for the chkdsk.  I had even coded an
exclude statement for the corrupt file, but ADSM was not able to skip
it.

Angel Boles

Westinghouse Electric
(412) 642-5944
Win 272-5944
bolesav AT westinghouse DOT com

> ----------
> From:         Booher, Joelle M[SMTP:jmbooher AT amp DOT com]
> Sent:         Monday, September 08, 1997 9:51 AM
> To:   ADSM-L AT VM.MARIST DOT EDU
> Subject:      ANS4253E File I/O error...
>
> Good Monday morning!
>
> I am running ADSM Server for NT, PTF3.  This weekend one of our
> clients
> got the following error:
>
> 09/06/1997 03:00:56 Expiring-->            426,975
> E:\data\Mpro\CHUCK.$$D  Sent
> 09/06/1997 03:00:56 Expiring-->             17,348
> E:\data\Mpro\CHUCK.$$X  Sent
> 09/06/1997 03:00:58 ANS4102I ***** Processed   227,500 files *****
> 09/06/1997 03:01:04 ANS4102I ***** Processed   228,000 files *****
> 09/06/1997 03:01:06 ANS4102I ***** Processed   228,500 files *****
> 09/06/1997 03:01:10 ANS4102I ***** Processed   229,000 files *****
> 09/06/1997 03:01:28 ANS4253E File input/output error
> 09/06/1997 03:01:28 Incremental backup of drive 'F:' with label
> 'TYPHOONF'
> 09/06/1997 03:01:38 Directory-->                 0 F:\INSTALLR  Sent
>
> As you can see, it was backing up drive E: at the time that the error
> occurred, then went right to drive F:.  Unfortunately there are about
> 10,000 more files on drive E: that it never attempted to backup.  Upon
> investigation, it appears that there is a corrupt file in one of the
> subdirectories on drive E: which cannot be deleted.  Microsoft has
> instructed the admins of that NT server that they will need to run a
> chkdsk -f, and reboot the server before the file gets cleaned up.  The
> admins have informed me that they can not bring the server down until
> next weekend.  AND, to complicate matters, they do not feel
> comfortable
> running that chkdsk unless they have good backups - which they are not
> getting because of the I/O failure.  I ran a selective of all of those
> directories so that they would have backups of Friday's updates, but I
> can't continue to do that all week because it's causing good versions
> to
> be pushed out, and it's flooding my already 14Gb database!
>
> Here's my question (finally!):  How do I get ADSM to totally ignore
> the
> corrupt file so that the rest of the files on that drive will be
> backed
> up?  It appears that even if I exclude the file, ADSM tries to read it
> or something because I still get the error/failure.
>
> Any suggestions?
>
> Thanks in advance for your help....
> Joelle Booher
> Amp Incorporated
> (717)810-2816
> jmbooher AT amp DOT com
>