I have a puzzling situation on a HPFS disk. I used Rexx to
write a big file until there were zero bytes left available.
This was to try to expunge the data from deleted client files
without having to zap the whole disk or use any extra
utilities.

To my surprise, even with the disk completely full, confirmed
by both OS/2 and DOS, File Phoenix still lists some of the
deleted client files -- and even more odd, it can still *view*
the data in those files. Which brings up the question, where
on earth is that data hiding, on a disk that now has zero bytes
free?

On further investigation with ChkDsk from a floppy boot I
noticed that it sees 2441k still available. But OS/2's dir
command says 0 bytes. So which is it? ChkDisk is apparently
'right', because File Phoenix couldn't very well still read
deleted data on the disk if it was *really* full. But if OS/2
can't see the free space from the command line or PM, how on
earth did the data get there?

I don't think this is any kind of a 'large hard drive' problem.
This is an old PC, drive c (FAT) is only 267.5 megabytes, and
drive d (HPFS) is only 571 megabytes.

But for some reason, ChkDsk and apparently File Phoenix can
access nearly 2-1/2 megabytes of HPFS disk space that is
invisible to the OS/2 presentation manager, command line, Rexx,
and even the DOS box. It's not awfully important, but I'd love
to know the reason for this discrepancy.

Anyone have any ideas what is going on here?

On Thu, 11 Nov 2004 03:09:38 UTC Walt Gregg
<newsgroups@w-gregg.juneau.ak.us> wrote:

While the numbers don't exactly add up, I was under the impression
that HPFS would not fill every last byte on a disk due to the
structure of it's storage mapping. I may be wrong, but I do know that
for all the years I've used it the "conventional wisdom" is not to
fill an HPFS drive beyond about 90%.

As a solution, try DFSEE. It has a function to zero out unused space
on a drive. I don't think it's military grade cleaning but it should
suffice.


--
Will Honea

Hi Will, Walt

On Thu, 11 Nov 2004 05:24:51 UTC, "Will Honea" <whonea@yahoo.com>
wrote:

Me too, allthough 2.5 Mb is not that much on a large filesystem,
perhaps
the filesystem is a bit conservative in its report to the OS, while
chkdsk
reports the real figures ...

That helps in keeping fragmentation low since it will NOT try to use
up all
the small 'left-over' chunks of freespace then. It should not really
matter
for reliability I would say ...

Of course it has, at least starting from version 6.15 :-)

I just added that feature on a request from Australia, usage:

File -> Open partition to work with -> ... select the partition ...
Actions -> Erase, wipe selected areas -> SECUREWIPE freespace in FS

This is military spec, from the help-screen (use <F1> on that
menu-item):

++++++++++++
This will wipe all unused sectors or clusters in the current
filesystem
repeatedly as specified by the US military DoD 5520.22 specification.

It will remove any remains of deleted files or other garbage that was
on the partition. This will make any UNDELETE of files impossible!
(except for files in the Windows trashcan or OS/2 DELDIR)

This will make ANY recovery of the wiped (file) areas impossible!
++++++++++++

Wiping unused space is supported on FAT, FAT32, NTFS and HPFS.

Warning: It is REAL SLOW!

Regards, JvW

--
Jan van Wijk; Author of DFSee: http://www.dfsee.com

On Thu, 11 Nov 2004 03:09:38 UTC, Walt Gregg
<newsgroups@w-gregg.juneau.ak.us> wrote:

How big was the file? I would think that you would run out of room,
when there was not enough space to write the file. Now, if you were
writing a 2 GB file, to fill up the disk, you would run out of room,
with almost 2 GB of space unused. In 2 GB of space, you can write a
whole lot of smaller files. Since HPFS writes files in 512 byte
chunks, I would suggest that you need to write your large file, until
you run out of room, then write ever smaller files, until you cannot
write a 512 byte file. (Even then, the file system may not let you
fill it up that much).

As suggested in another post, DFSEE is a good tool to do that sort of
thing.

Hope this helps...
--
From the eComStation 1.2 of Doug Bissett
doug dot bissett at attglobal dot net
(Please make the obvious changes, to e-mail me)

Hi all. Doug, my Rexx script did basically what you said; when
Rexx tries to write more than will fit, it tells how much did
not get written, and I used that info to write smaller and
smaller records until exactly 0 bytes were left free. But that
apparently doesn't suffice; there is always that chkdsk-seeable
chunk that doesn't get cleared and is reachable by File Phoenix
and DFSee. Maybe HPFS was intended to have this as a
'feature', a sort of last-ditch undelete zone.

Thanks for the tip on DFSee, Will. I downloaded it and while
it's a bit intimidating, it did the job just fine, thoroughly
zapping *all* the remnants of old deleted files. File Phoenix
can't even see the old names, let alone their contents. And
DFSee can do what File Phoenix does, so I won't have have to
limit my hpfs drives to 2 gigabytes any more (File Phoenix
didn't work for me on large drives).

Jan, DFSee is a very nice program. I particularly like the
wipe function's -t switch to just test it. That increased my
comfort level a lot before actually turning it loose on my
disk. I didn't bother with the DoD/government level of wipe. I
think your option of overwriting with random data is perfectly
adequate for all practical purposes, so I used:

dfsos2 -b vol -q d: # wipe r -f # quit

Worked flawlessly. Took about 10 minutes to clear about 70
megabytes of free space, but this 2nd hand PC runs at only
66MHz. The only drawback I can see is that you warn us that
the disk shouldn't be in use. Not wanting to take any chances,
I booted from a floppy to try this. It would be a little more
convenient if it was safe to run this function without needing
to do that.

I know there's a lot of stuff out there about the need to run a
Guttman dozens-of-times wipe or a DoD style wipe, but I just
don't agree that it's necessary. I've read Guttman's paper,
his followup, and there is a more recent paper by Garfinkel,
'Remembrance of Data Passed: A Study of Disk Sanitization
Practices' (2003), all of which convince me that just
overwriting with random data, different every time you run it,
is more than adequate for all practical purposes. It was the
Garfinkel paper that caught my attention -- one of the examples
is a 2nd hand PC that turned out to be a law firm's old file
server with all the client data intact. Scary. There really
is a need to be able to wipe free space without the trauma of
reinstalling -- I know, there's leftovers in swap files, ini
files, caches, etc, etc, but just wiping free space is way
better than doing nothing. I guess GammaTech and Graham
utilities have wipers too, but DFSee has pretty good undelete
or wipe and the rest of the disk utilities are pretty
extensive, so I've just send in a registration

-w-

On Thu, 11 Nov 2004 21:58:18 UTC, Walt Gregg
<newsgroups@w-gregg.juneau.ak.us> wrote:

Which is exactly why it is there, I really needed that while
developing :-)

Yes, that is there for the paranoid only, and people that are
forced by company (government ?) rules to do so ...


That is OK, allthough instead of selecting the volume as you do
with the "vol" command, I would probably selected the partition
it lives in using the "part" command.

The "vol" command only works for filesystems recognized by
the operating system you are running, so you would not be able
to wipe an HPFS volume from the DOS version for example ...

The only time I normally use "vol" is to work on diskettes.

"VOL" also adds more layers of software making it a bit slower.

That is almost impossible to implement, it is different on all
operating systems, and most filesystem-drivers have no
interfaces to support that ...

I will not bother :-)

<snip>

OK, good :-)


Regards, JvW


--
Jan van Wijk; Author of DFSee: http://www.dfsee.com