Re: Finding REALLY hidden files?

On Thu, 11 Oct 2007 11:12:01 -0700, in 'rec.video.desktop',
in article <Re: Finding REALLY hidden files?>,
Gene E. Bloch <spamfree@xxxxxxxxxxxxxx> wrote:

On 10/11/2007, Martin Heffels posted this:
On Mon, 08 Oct 2007 20:48:53 GMT, xeaglecrest@xxxxxxx wrote:

Don Stauffer in Minnesota wrote:

On Oct 6, 11:08 am, "Richard Crowley" <rcrow...@xxxxxxxxx> wrote:
"Don Stauffer in Minnesota" wrote ...

My wife frequently comes up with this problem. Her working ( D )
drive is almost full. She has a project she is still working on, so
does not want to format disk. She cleans up all the old files she
(and I) can find from old projects. On her drive (a 500 GB unit) the
properties function of WE shows over 450 GB used, but looking in the
various folders we can only account for 200 GB. The remaining 250 GB
is completely hidden. This is AFTER defrag. I have checked the
options in the folder properties dialog, and we do NOT have "hide
hidden files" enabled.


Do a search by file size (1 GB or larger) and see if a bunch of stuff
shows up that you
thought was deleted.

Hopping on board a bit late here, and can't see the whole thread, so maybe
this has been suggested: make sure you got the latest version of your BIOS
installed. There used to be problems with BIOS'S causing large disksizes to
be read incorrectly.
Further, searh for "*.tmp" and "~*.*" to find temporary-files which might
not have been deleted. Another one is, if you render a lot while checking
your material, all the older renders are kept on your hard-disk.
Cleaning-out your render-queue helps as well (but you will loose your
renders).

cheers

-martin-

And here's another thought to add to this thread:

The disk storage for a file is allocated in fixed size units called
allocation units or clusters (there may be other names I'm unaware of).
Any left-over space in the last cluster of a file is lost, in that it
will never be used for any other data. Basically, you could say that
when measured (allocated) in clusters, the file size is always rounded
up.

This means that if the cluster is 32KB and the file length is 12 times
32 KB plus one byte, the allocated space is 13 clusters, and 32767
bytes of the 13th cluster are not used.

In some info displays, e.g. file properties in Windows Explorer, the
file size is reported like this:

Size: 223 bytes (223 bytes)
Size on disk: 4.00 KB (4,096 bytes)

The above is copied and pasted from the right-click properties box for
one of my files chosen at random (I'm using NTFS).

The size on disk is not normally diplayed in the regular Explorer
window.

OK, last step: imagine that you have a large cluster size (typical in
FAT32) and a thousand small files, each one wasting 31 KB. The reported
total file size is 1,000 KB; the actual space used is 32,000 KB.

I have no idea if this applies to the OP's situation; typically the
wastage averages out to not too much.

Oh yes - I believe there are free downloadable utilities that will
compute the wastage for a specific partition. IIRC, "wastage" is more
normally called "slack", if you care to Google for such a program.


Not to be picky, but slack space is slightly different than the space
lost due to space being allocated in terms of clusters.

Virtually all hard disk drives use, at the physical level, a sector
size of 512 bytes (newer standards with larger sector sizes have been
proposed, but aren't yet in common use). Because of this, the drive
itself always reads and writes data in terms of sectors. So, if you
have a file whose length isn't an exact multiple of 512 bytes, that
wasted space within that last, partially used, sector of the file is
called slack space.

Example: a file that is one byte in length will still consume 512
bytes (one sector) on disk, even if the cluster size happens to also
be 512 bytes. In that case, the slack space is 511 bytes.

That's the worse case scenario, of course. A file which is 511 bytes
in length would only have slack space of one byte.

Slack space has nothing to do with space wasted due to having a large
number of small files on a partition that's been defined as having a
large cluster size (allocation unit size). I have seen partitions with
many thousands, even tens of thousands, of small files, where the
cluster size was 32 kB, thus causing a *lot* of wasted space on the
partition. This is an example of where it would have been more
efficient, from a space utilization viewpoint, of using a small, say 4
kB, cluster size when creating the partition.

There are programs on the market which, for security reasons, can
erase (write over) slack space at the end of files so that that data
can't be recovered. Sometimes interesting things can be found in slack
space. :)

--
Frank, Independent Consultant, New York, NY
[Please remove 'nojunkmail.' from address to reply via e-mail.]
Read Frank's thoughts on HDV at http://www.humanvalues.net/hdv/
(also covers AVCHD and XDCAM EX).
.

Relevant Pages

  • Re: Correcting corrupt $MFT on shared clustered disk.
    ... against a cluster disk. ... handles against the disk. ... After digging into it I figured out I didn't need the extended maintenance mode and figured out the rest of the article. ... If I assign drives for different areas, I figure we'll eventually end up with the same problem we had before: some areas running out of space and others with space to spare. ...
    (microsoft.public.windows.server.clustering)
  • Re: Correcting a corrupted $MFT on a shared clustered disk
    ... Also, the problem I'm having is on the smaller basic disk, the GPT one is ... When I do run chkdsk, are there any special issues with the cluster? ... The three drives are a 500MB for the quorum, ...
    (microsoft.public.windows.server.general)
  • Re: Windows 2003/SQL 2000 Cluster SAN Migration
    ... Isin't the W2K3 Cluster Server Recovery tool designed to ... > 4) assume the Old disk drive is O: and the New disk Drive is N: ... > 4) Create a new Disk Resource for the new disk and have that in the SQL ... >>just fine but not the data drives, basically on step 14 my old drives ...
    (microsoft.public.windows.server.clustering)
  • Re: Correcting a corrupted $MFT on a shared clustered disk
    ... Phase 1 went through pretty fast, it found and corrected the 60 or so corrupted attribute & orphaned records that the read-only chkdsk passes were detecting. ... Also, the problem I'm having is on the smaller basic disk, the GPT one is ... are there any special issues with the cluster? ... The three drives are a 500MB for the quorum,> and two ...
    (microsoft.public.windows.server.general)
  • Re: Correcting a corrupted $MFT on a shared clustered disk
    ... Also, the problem I'm having is on the smaller basic disk, the GPT one is ... for the CHKDSK, or is it something that's only going to get worse? ... are there any special issues with the cluster? ... The three drives are a 500MB for the quorum, ...
    (microsoft.public.windows.server.general)