inconsistent highwater mark and EFBLK

[John Abbott_2]

I'm with Volker, I wouldn't want a backup restore or an anal/disk operation take ages. We have GB sized DB container files that are marked /nobackup, they are usually locked (db up - phew!) but sometimes on development the database is down, if a backup is taken I don't want them included and for a restore I would not like to have binary zeros written.

just my 2eur too!

J.

[Volker Halle]

Jan,

maybe we should take the %ANALDISK-I-BADHIGHWATER, message as just as is is: an informational message, that there are files on the disk, which have not been overwritten by zeroes.

Once you understand what the message means, things get much clearer...

Volker.

[Jan van den Ende]

Volker,

I could well live with that, _IF_ the message itself and/or the HELP on it would explain it clearly, clear also to those who encounter it for the first time, and have not gone through this or similar "outside" explanations.

Proost.

Have one on me.

jpe

[Stanley F Quayle]

How about ANALYZE/DISK/REPAIR=HIGHWATER, with the default behavior of /REPAIR be NOHIGHWATER?

Also, while we're hacking on ANALYZE/DISK, how about suppressing "error" about QUOTA.SYS if quotas are not in use?

[Ian Miller.]

http://www.hpuseradvocacy.org/node/add/issue/43

:-)

[Andrea Arthur]

Well as previously stated, thank you all.
I guess I am glad that I asked the question "Why SET file/owner=[xxx] resolves this issue?"

Thanks again for your thoroughness and due dilligence. For the record I created new page and swap files and deleted the old ones.