Bill said:
Then you might want to look at repartitioning the HDD on which is the
partition containing the OS (if you only have 1 HDD). Resize (make
smaller) the OS partition leaving enough free disk space to create a new
partition that you format at FAT32. Use the FAT32 to store your big
collection of files until you get around to copying/moving them to the
USB FAT32 drive.
Note: If you move instead of copy, you might want to consider disabling
the Recycle Bin on the drive for the FAT32 partition. Moving incurs
deletion, and deletion is performed by checking if the Recycle Bin has
enough space to move a "deleted" file to that holding area. Tracking
the deletes takes time. Also, if there isn't enough room in the Recycle
Bin to delete 1 file then the latest file gets deleted from the Recycle
Bin, it checks if there is enough room for the targeted file to delete,
if not then it deletes the next latest file, and so on until there is
enough room to move the deleted file into the Recycle Bin. If the next
file to delete is huge, this same process repeats. If you delete
hundreds or thousands of files at a time, or you move that many files
which incurs the deletes, then you'll notice a big change in time to
complete a huge delete or move job with the Recycle Bin disabled on that
drive. Of course, that means losing the safety net. However, if you're
deleting or moving hundreds of huge files, not many are retained in the
Recycle Bin at any moment since they have to get deleted from there to
make room for the next huge file.
Also forensically speaking. And security speaking. I think eliminating
a file on fat32 would be better done than with ntfs. The journal
keeps a copy of the file I would think after its deleted with ntfs.
Not that I am aware of. Deleting a file in either file system merely
unallocates clusters that were previously assigned to a file. If the
file was small enough (a bit under 4 KB) to fit into the MFT allocation
unit then the file is stored there. Deleting that file merely makes
that MFT record available to another file sometime later but the file
within is not altered until that MFT record gets reused. On FAT, a
secure delete merely had to look at the chain of file table records for
the clusters containing the file and do its erasing on those clusters.
In NTFS, the same happens but the utility would also have to know about
MFT-contained files to erase those, too.
On the fats, a bit is changed and everything is eventually rewritten
over. I don't no with ntfs. With the MFT and mirror MFT files may
never completely go away. I don't have anything illegal on my file
system that I'm aware of but When I shred a file I want it gone not
hanging around in a journal. So the "safety" features of ntfs work
both ways. Sure they help protect data I understand. But they IMO
sound like they (journals) sound like they keep things hanging around
too.
Unless the secure delete utility says it will inspect the journaling
sectors, those won't get wiped. Secure deleting a file means multiple
wipes on the clusters that are/were assigned to it. I don't know if any
journaling sectors holding bits of a file are part of the MFT record for
the file. I never delved that deep into NTFS. There is the included
'fsutil' console-mode program that can manipulate the journal; however,
my only use of fsutil regarding journaling in NTFS was to turn it off
and back on but I don't remember if that was to help with defrag or to
wipe the journal's sectors. Since this is software, I figured other
utilities could also manipulate the journal, and found:
http://www.mydefrag.com/VolumeActions-DeleteJournal.html
The journal sectors on the HDD do not contain a file, per se. They
retain deltas: changes to files. I don't know that deleting the journal
(and recreate it) will actually erase anything that was previously help
in any sector previously used by the journal (and creating a new journel
doesn't necessarily reuse the same sectors as before). So I suspect you
not only need to securely delete a file but occasionally you may want to
securely wipe the free space on the drive. Before I did anything that
major, I'd save a backup (after the [secure] file deletes) to make sure
the cleanup tool didn't go amok and erase sectors it shouldn't have.
As noted at
https://technet.microsoft.com/en-us/library/cc976808.aspx,
those deltas are a persistent log of changes but once the data within
each delta has been written to the file than that same journaling sector
gets reused for other changing files. If forensics are used, I suspect
the hacker would go after your pagefile before trying to use a disk
editor to find what had been left in the sectors for NTFS journaling.
Journaling sectors get reused a lot. Alas, they often get scattered in
bunches around the HDD's platters for a partition. This means you may
find that you can never a really huge file because there isn't enough
space between the journaling sectors on the HDD that would accomodate
all of the huge file. I ran into that, used some utility to tell me
where they were, and figured there was not enough space between them for
the really huge file that I was trying to defragment. The only way to
defrag the huge file into a single segment was to copy it elsewhere,
reformat the partition (which meant restoring the OS from backups),
defragment, and then copy the huge file back to that partition. Yeah,
it worked but really it wasn't worth it. I was just determined, or
maybe it was obstinence, to see if it could be done.
Because forensics usually goes after the pagefile to pick up pieces of
files (and also the memory to find data from there), some folks
configure Windows to zero out the pagefile on shutdown of Windows. This
isn't as secure as, say, using an eraser utility that makes multiple
passes on the same cluster. Also, the zeroing out of the pagefile's
sectors takes time so the shutdown takes a lot longer. Deleting files
in the file system does not affect the partial bits of a file that are
in the pagefile. Only the cluster getting reused (overwritten) by other
data would wipe out the old data there.
More info on NTFS is here:
http://www.ntfs.com/. It doesn't have
everything about NTFS but it's a good starting point. I'm sure there
are some paranoid, er, security conscience forums or newsgroups out
there where their inhabitants know a lot more about ensuring your data
remains secure and and you delete isn't in memory, the pagefile, a
portion in any journaling sector, not in the HDD's cache, and if using a
secure delete utility is sufficient (and which ones cover all those
areas) or if you really need to get a HDD and software tool that support
the Secure Erase feature in some HDDs.
I only vaguely remember looking at some secure erase software
(
http://cmrr.ucsd.edu/people/Hughes/secure-erase.html, freeware, and
http://partedmagic.com/secure-erase/, payware) that was used to tell a
Smart Erase capable disk to do its secure erasing. Not all HDDs support
Smart Erase but I think all SSDs do.
My brain hurts. Time for a smoothie.
