«

I have written this short program to empty out files. It works great
except that it truncates. My guess was that it was in the fopen mode
somewhere but I have played with that and the same results. Empty file of
zero bytes. If I have a 512 byte file of data, I want 512 bytes of '\0'.
Pardon the exit(1)'s. It's hort hand on my implementation for
exit(EXIT_FAILURE); The macro is defined on my implementation as 1.

Bill

/* se, secure erase */

#include <stdio.h>
#include <stdlib.h>

int main(int argc, char *argv[])
{
if (argc != 2) {
puts("se usage error");
exit(1);
}
int i, j;
FILE *fo, *fw;
if ((fo = fopen(argv[1], "ab")) == NULL) {
printf("%i\n", ferror(fo));
clearerr(fo);
fclose(fo);
exit(1);
}
if ((fw = fopen(argv[1], "ab")) == NULL) {
printf("%i\n", ferror(fw));
clearerr(fw);
fclose(fw);
exit(1);
}
while ((i = getc(fo)) != EOF)
putc(j = 0, fw);
fclose(fo);
fclose(fw);
return 0;
}

On Nov 19, 12:26 am, "Bill Cunningham" <nos...@nspam.invalid> wrote:

> Pardon the exit(1)'s. It's hort hand on my implementation for
> exit(EXIT_FAILURE); The macro is defined on my implementation as 1.

Bill Cunningham on portability. Priceless

<> wrote in message
news:033779ff-588a-4b94-82fb-...

> Bill Cunningham on portability. Priceless

I only plan to use this on my system. Or else believe me it would be
exit(EXIT_FAILURE);

"Mark McIntyre" <> wrote in message
news:gDHUk.94294$...

> By the way this isn't a very secure erase. You'd need to write at least
> seven different bitpatterns over the entire file sequentially.

I kind of figured it wouldn't be. Thanks. I'll figure out something with
for() for that.

Bill

Hi

On Tue, 18 Nov 2008 18:06:39 -0500, Bill Cunningham wrote:

> "Mark McIntyre" <> wrote in message
> news:gDHUk.94294$...
>
>> By the way this isn't a very secure erase. You'd need to write at least
>> seven different bitpatterns over the entire file sequentially.
>
> I kind of figured it wouldn't be. Thanks. I'll figure out something
> with for() for that.

This only works if the file system overwrites in-place. If not you are
just wasting effort.

See the documentation and source of your platform's shred(1) for pointers.

viza

Hi

On Tue, 18 Nov 2008 17:26:41 -0500, Bill Cunningham wrote:

> I have written this short program to empty out files. It works great
> except that it truncates. My guess was that it was in the fopen mode
> somewhere but I have played with that and the same results. Empty file
> of zero bytes. If I have a 512 byte file of data, I want 512 bytes of
> '\0'. Pardon the exit(1)'s. It's hort hand on my implementation for
> exit(EXIT_FAILURE); The macro is defined on my implementation as 1.


> if ((fo = fopen(argv[1], "ab")) == NULL) { ...
> if ((fw = fopen(argv[1], "ab")) == NULL) { ...
>
> while ((i = getc(fo)) != EOF)
> putc(j = 0, fw);

Opening the file twice is a bad idea.

"a" is append. You want "r+b", and then fseek() to the end and then
ftell() to get the length and then rewind() and fwrite() in large-ish
blocks for some semblance of efficiency. Also, see my other reply.

"viza" <> wrote in message
news:n6IUk.4588$2...

> This only works if the file system overwrites in-place. If not you are
> just wasting effort.
[snip]

What do you mean? If the filesystem is mounted in rw mode? I guess if it's
mount in ro it would do no good.

Bill

On Tue, 18 Nov 2008 20:35:09 -0500, Bill Cunningham wrote:

> "viza" <> wrote in message
> news:n6IUk.4588$2...
>
>> This only works if the file system overwrites in-place. If not you are
>> just wasting effort.
> [snip]
>
> What do you mean? If the filesystem is mounted in rw mode? I guess if
> it's mount in ro it would do no good.

If you open a file and write over its contents, sometimes the operating
system writes the new data to the same blocks where the old data was and
does not change which blocks make up the file. In other systems it first
writes the data to a new block, then changes the file to refer to the new
block. The old block is then released back to be reused, without ever
being overwritten whether you try to overwrite it or not.

Someone with low-level access to the disk can look for recently released
blocks and get access to the data that a naive shredding program like
this has left behind, in just the same way as if you had deleted the file
and recreated it.

HTH
viza

"viza" <> wrote in message
news:B9KUk.8395$2...

> If you open a file and write over its contents, sometimes the operating
> system writes the new data to the same blocks where the old data was and
> does not change which blocks make up the file. In other systems it first
> writes the data to a new block, then changes the file to refer to the new
> block. The old block is then released back to be reused, without ever
> being overwritten whether you try to overwrite it or not.
>
> Someone with low-level access to the disk can look for recently released
> blocks and get access to the data that a naive shredding program like
> this has left behind, in just the same way as if you had deleted the file
> and recreated it.

Sounds like WFP. I hate not being allowed to erase my system critical
files. Atleast they say they are.

"Bill Cunningham" <> writes:
> <> wrote in message
> news:033779ff-588a-4b94-82fb-...
>
>> Bill Cunningham on portability. Priceless
>
> I only plan to use this on my system. Or else believe me it would be
> exit(EXIT_FAILURE);

Why on Earth don't you just write "exit(EXIT_FAILURE);" in the first
place? You've wasted far more time trying to justify your
non-portable code than it would take to make it more portable.

If there were some system-specific advantage to using the less
portable code, then that would be fine -- but by your own admission,
exit(1) does exactly the same thing as exit(EXIT_FAILURE) on your
platform.

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"