On Wed, Dec 16, 2009 at 9:49 PM, Dale <rdalek1...@gmail.com> wrote:
> Joshua Murphy wrote:
>> That is, of course, when shredding individual files, where the final
>> location and initial locations for them may not wind up being the same
>> place on disk. When 'shredding' a whole partition, though, the file
>> system itself ceases to matter, as it in itself is being overwritten
>> as well as all the data it provides a means of indexing for.
>>
>> Incidentally, I believe the oft referenced here DBAN uses shred
>> internally, last I looked.
>>
>>
>
> That makes sense. So, the OP shouldn't mount the drives but shred the disk
> itself?
>
> Dale
>
> :-) :-)
I'm not at all sure *how* running shred on a mount point, as is
mentioned in one of the responses, would really work... as I can't
imagine it would have direct access to the underlying filesystem, and
as it's pointed at, as far as it ought to care, a folder... I don't
think it would do much of anything... but since my curiosity's
piqued...
chicane ~ # dd if=/dev/zero of=tmp.img bs=1M count=20
20+0 records in
20+0 records out
20971520 bytes (21 MB) copied, 0.102701 s, 204 MB/s
chicane ~ # mkfs.ext3 tmp.img
mke2fs 1.41.9 (22-Aug-2009)
tmp.img is not a block special device.
Proceed anyway? (y,n) y
Filesystem label=
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
5136 inodes, 20480 blocks
1024 blocks (5.00%) reserved for the super user
First data block=1
Maximum filesystem blocks=20971520
3 block groups
8192 blocks per group, 8192 fragments per group
1712 inodes per group
Superblock backups stored on blocks:
8193
Writing inode tables: done
Creating journal (1024 blocks): done
Writing superblocks and filesystem accounting information: done
This filesystem will be automatically checked every 23 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.
chicane ~ # mount -o loop tmp.img test/
chicane ~ # echo hello > test/test.txt
chicane ~ # shred test/
shred: test/: failed to open for writing: Is a directory
chicane ~ # shred -v -n 25 -z -u ~/test/
shred: /root/test/: failed to open for writing: Is a directory
chicane ~ # umount test
chicane ~ # shred -v -n 25 -z -u tmp.img
shred: tmp.img: pass 1/26 (random)...
shred: tmp.img: pass 2/26 (924924)...
shred: tmp.img: pass 3/26 (6db6db)...
shred: tmp.img: pass 4/26 (222222)...
shred: tmp.img: pass 5/26 (555555)...
shred: tmp.img: pass 6/26 (aaaaaa)...
shred: tmp.img: pass 7/26 (777777)...
shred: tmp.img: pass 8/26 (db6db6)...
shred: tmp.img: pass 9/26 (dddddd)...
shred: tmp.img: pass 10/26 (111111)...
shred: tmp.img: pass 11/26 (492492)...
shred: tmp.img: pass 12/26 (249249)...
shred: tmp.img: pass 13/26 (random)...
shred: tmp.img: pass 14/26 (888888)...
shred: tmp.img: pass 15/26 (cccccc)...
shred: tmp.img: pass 16/26 (eeeeee)...
shred: tmp.img: pass 17/26 (333333)...
shred: tmp.img: pass 18/26 (444444)...
shred: tmp.img: pass 19/26 (bbbbbb)...
shred: tmp.img: pass 20/26 (999999)...
shred: tmp.img: pass 21/26 (000000)...
shred: tmp.img: pass 22/26 (b6db6d)...
shred: tmp.img: pass 23/26 (ffffff)...
shred: tmp.img: pass 24/26 (666666)...
shred: tmp.img: pass 25/26 (random)...
shred: tmp.img: pass 26/26 (000000)...
shred: tmp.img: removing
shred: tmp.img: renamed to 0000000
shred: 0000000: renamed to 000000
shred: 000000: renamed to 00000
shred: 00000: renamed to 0000
shred: 0000: renamed to 000
shred: 000: renamed to 00
shred: 00: renamed to 0
shred: tmp.img: removed
(note that for 'special files' like real block devices, it doesn't do
the rename/remove that it does for normal files)
--
Poison [BLX]
Joshua M. Murphy
