Yes, that's a variation of the command I used in the shreddir script I presented above: which can be rewritten as: I just piped the find ouput through a 'while' loop instead of using the '-exec' switch.........Both accomplish the same thing, however using the '-exec' switch as you've shown would probably be slightly faster (maybe a few milliseconds per file found) than running it through a loop since it will execute the 'shred' command immediately as each file is found.......


PS: I suppose I've gotten into the habit of piping the output of the 'find' command to another command, that I never think of ways to use the '-exec' switch instead......

I thought the reason why "shred" doesn't work on "reiser and ext3 " is because it can't wipe the whitespace.

this works perfeclty fine but how can I change the number of times it overwrites? you have it as -2, but how can I change that on commandline?


but how can you specify the directory with this? where?

Right after the find command, say you want shred files in /home/smokey/scandalousfiles directory

If you want to be able to specify the number of overwrites through the command line when using the script, then change the number "2" in the SHRED variable at the top to $2 (Note: $2 is a built-in positional variable which tell bash to substitute the second argument on the command line).......It should read like this:

SHRED="`which shred` -uvzn $2"

Cedrik answered this question, but if you want to use it in the script, use it just the way I have it...............Replace the find command in the script which follows "( cd $1 ;" exactly as I have shown so it looks like this:

( cd $1 ; find * -type f -maxdepth 0 -exec $SHRED {} \; )

That first part with the "cd $1" means to change to the directory supplied on the command line ($1 is the built-in positional variable telling bash to substitute the first argument on the command line)..............What you are doing is going into the target directory itself before shredding the files in that directory............

If you plan on supplying the number of passes through the command line arguments, then you should also change the error-checking routine to reflect this.............Here's a rewrite of the script taking all these changes into account: Remember, this will only work on the files is the given directory supplied on the commandline and will ignore any subdirectories..........This is more for safety to avoid unintentionally wiping files in other directories that may be wanted or needed...........

Shred may have problems with journaled filesystems, but Smokey says he's using ext2, which is not a journaled filesystem, so shred will do what it's supposed to do.........

Geekster, what I'm imagining isn't a once-size fits all shred command, something more along the lines of codecs for video players... Do you consider mplayer to be bloated?

You could configure shred at compile time with the filesystems you use...
I'd hardly consider that bloat.

Maybe it's time to pick up that C book again and learn the innards of my filesystems :-)

--Shade

Why not?..........Especially if it can be done simply and efficiently...........Otherwise that "modular" approach" has merit.......

That would be hard to do since shred is part of the coreutils package and there isn'a a way to pass any special configuration options for shred............You would have to go to the source file (shred.c) in the coreutils package and modify it directly before compiling (maybe even making a patch for others to use)...........


But I just thought of a workaround (a variation of my idea above) which just might work on journaled or log-based filesystems.............Why not create an empty sparse file which fills up the remaining free space just before shredding the target files and removing that empty file afterward.........

Creating an empty sparse file is a trivial matter using the 'dd' command, and is _much_ faster to create than creating a dummy file filled with zeros.................You would just need to know the remaining amount of free space (as the number of blocks) on the partition that contains the target files.................Which is where the 'df' command comes in handy.........

For example, to find and isolate the amount of free space where the file to be shredded resides, using a block size of 512 bytes (the default size for 'dd'), you would run this command: "FILENAME" is the name of the file to be shredded. This will ouput the amount of free space as a number of 512-byte blocks...............Now you can create the dummy sparse file with 'dd' command using the output of the 'df' command like so: "DFOUT" would be the output of the previous 'df' command and you would have to make sure that the "dummy" file is created in the same partition, but in a different directory, where the file to be shredded is located.....................Since you're not actually writing anything to the disk, just merely creating the boundaries of a file of a certain size, the process should only take as long as the 'seek' option takes in the 'dd' command...........

I haven't tested this, but it seems like a feasible thing to do -- that is, if the filesystem in question will allow overwriting of files in place............Of course, this would be absolutely useless on any type of RAID setup since the purpose of RAID is redundancy, or where any kind of automatic backup system is in place which take snapshots every few minutes...........


PS: I'm using the term "sparse" rather loosely.............As I understand it, a sparse file merely has isolated bits of data with large areas of non-data (zeros) scattered throughout the file..............Usually, a filesystem which can properly handle sparse files will not allocate any space to the empty portions, but only retain pointers to the valid data, thus saving on disk space..........Here, I'm allocating all the free space to one big empty file to use up all the available disk space without actually writing anything to the disk in order to save some time..............

Oh well, scratch that idea..................It won't work on reiserfs because reiserfs will treat that dummy file as a sparse file...................On my Root partition ( / ), I have about 1.3G free space................After creating that dummy sparse file, the 'ls -l' command shows it as being a 1.3G file, but the 'df' command still shows 1.3G of free space left...................

A sparse file on linux will show it's full size with ls -l or du, but only occupies the space of the data in the file. If you put the sparse file on windows it will OCCUPY it's full stated size.