7 pass file erasure [closed]

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP





.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;







up vote
-2
down vote

favorite












I am an aspiring C++ programmer and I have been programming for a few years off and on but I don't have much usable knowledge. Right now I am working on filesystem safety so I decided to write an erasure (think BleachBit).



It needs to be run from terminal as such (root/ program filename.something) and needs to open the file in memory, get file size, write in raw binary format to each bit of file, close file,. This is a part where I am stuck. It needs to delete the (I am pretty sure it's some kind of pointer) object that represents
the file that the system stores by wiping it from memory.



ren.cpp:



#include <stdio.h>
#include <string>






void bitwrite(int pass, char * fn)

FILE * fp;
fp = fopen(fn, "wb");
int k;
const void * kptr;
switch(pass)

case 0:
k = 0b11111111111111111111111111111111;
break;
case 1:
k = 0b10101010101010101010101010101010;
break;
case 2:
k = 0b01010101010101010101010101010101;
break;
case 3:
k = 0b11111111111111111111111111111111;
break;
case 4:
k = 0b10101010101010101010101010101010;
break;
case 5:
k = 0b01010101010101010101010101010101;
break;
case 6:
k = 0b00000000000000000000000000000000;
break;

fseek(fp, 0, SEEK_END);
off_t size = ftell(fp);
fseek(fp, 0, SEEK_SET);
for(int a = 0; a<sizeof(size);a++)

fseek(fp, a, SEEK_SET);
fwrite(&k, sizeof(int), 1, fp);


fclose(fp);


int main(int argc, char * argv)


if(argv == NULL)

printf("usage: ren file to be destroyed");
return 1;

for(int i=0;i<7;i++)

bitwrite(i, argv[1]);


printf("success!");

return 0;



This code needs to run efficiently as possible. I am at a loss as how to improve and fix errors. Currently, C++ ren.cpp -o ren runs without error, but gdb throws a sigseg error @fseek.







share|improve this question













closed as off-topic by Jamal♦ Jun 5 at 2:52


This question appears to be off-topic. The users who voted to close gave this specific reason:


  • "Code not implemented or not working as intended: Code Review is a community where programmers peer-review your working code to address issues such as security, maintainability, performance, and scalability. We require that the code be working correctly, to the best of the author's knowledge, before proceeding with a review." – Jamal
If this question can be reworded to fit the rules in the help center, please edit the question.












  • You forgot to set fp before you call fseek. Did you mean for the result of the call to fopen to be set to fp?
    – jbapple
    Jun 5 at 0:25










  • i think so? im not fully familiar with file io
    – user171218
    Jun 5 at 0:34






  • 1




    Then there's the effects of caching by the OS., And the (remote) possibility that when you open the file later it might not be written to the same physical location on the disk. Either one will keep your scheme from working.
    – 1201ProgramAlarm
    Jun 5 at 0:36






  • 2




    The multi-pass thing does not help on modern drives. One pass of random data is sufficient. And it might not work at all, if sector remapping takes place!
    – JDługosz
    Jun 5 at 1:25






  • 1




    You can not do what you are trying to do from with file system calls (that is a layer of abstraction too far away). The file interface provided by the OS does not give you that much control of how it interacts with the blocks on the disk. You need to look at the block interface provided by your hardware.
    – Martin York
    Jun 5 at 15:06
















up vote
-2
down vote

favorite












I am an aspiring C++ programmer and I have been programming for a few years off and on but I don't have much usable knowledge. Right now I am working on filesystem safety so I decided to write an erasure (think BleachBit).



It needs to be run from terminal as such (root/ program filename.something) and needs to open the file in memory, get file size, write in raw binary format to each bit of file, close file,. This is a part where I am stuck. It needs to delete the (I am pretty sure it's some kind of pointer) object that represents
the file that the system stores by wiping it from memory.



ren.cpp:



#include <stdio.h>
#include <string>






void bitwrite(int pass, char * fn)

FILE * fp;
fp = fopen(fn, "wb");
int k;
const void * kptr;
switch(pass)

case 0:
k = 0b11111111111111111111111111111111;
break;
case 1:
k = 0b10101010101010101010101010101010;
break;
case 2:
k = 0b01010101010101010101010101010101;
break;
case 3:
k = 0b11111111111111111111111111111111;
break;
case 4:
k = 0b10101010101010101010101010101010;
break;
case 5:
k = 0b01010101010101010101010101010101;
break;
case 6:
k = 0b00000000000000000000000000000000;
break;

fseek(fp, 0, SEEK_END);
off_t size = ftell(fp);
fseek(fp, 0, SEEK_SET);
for(int a = 0; a<sizeof(size);a++)

fseek(fp, a, SEEK_SET);
fwrite(&k, sizeof(int), 1, fp);


fclose(fp);


int main(int argc, char * argv)


if(argv == NULL)

printf("usage: ren file to be destroyed");
return 1;

for(int i=0;i<7;i++)

bitwrite(i, argv[1]);


printf("success!");

return 0;



This code needs to run efficiently as possible. I am at a loss as how to improve and fix errors. Currently, C++ ren.cpp -o ren runs without error, but gdb throws a sigseg error @fseek.







share|improve this question













closed as off-topic by Jamal♦ Jun 5 at 2:52


This question appears to be off-topic. The users who voted to close gave this specific reason:


  • "Code not implemented or not working as intended: Code Review is a community where programmers peer-review your working code to address issues such as security, maintainability, performance, and scalability. We require that the code be working correctly, to the best of the author's knowledge, before proceeding with a review." – Jamal
If this question can be reworded to fit the rules in the help center, please edit the question.












  • You forgot to set fp before you call fseek. Did you mean for the result of the call to fopen to be set to fp?
    – jbapple
    Jun 5 at 0:25










  • i think so? im not fully familiar with file io
    – user171218
    Jun 5 at 0:34






  • 1




    Then there's the effects of caching by the OS., And the (remote) possibility that when you open the file later it might not be written to the same physical location on the disk. Either one will keep your scheme from working.
    – 1201ProgramAlarm
    Jun 5 at 0:36






  • 2




    The multi-pass thing does not help on modern drives. One pass of random data is sufficient. And it might not work at all, if sector remapping takes place!
    – JDługosz
    Jun 5 at 1:25






  • 1




    You can not do what you are trying to do from with file system calls (that is a layer of abstraction too far away). The file interface provided by the OS does not give you that much control of how it interacts with the blocks on the disk. You need to look at the block interface provided by your hardware.
    – Martin York
    Jun 5 at 15:06












up vote
-2
down vote

favorite









up vote
-2
down vote

favorite











I am an aspiring C++ programmer and I have been programming for a few years off and on but I don't have much usable knowledge. Right now I am working on filesystem safety so I decided to write an erasure (think BleachBit).



It needs to be run from terminal as such (root/ program filename.something) and needs to open the file in memory, get file size, write in raw binary format to each bit of file, close file,. This is a part where I am stuck. It needs to delete the (I am pretty sure it's some kind of pointer) object that represents
the file that the system stores by wiping it from memory.



ren.cpp:



#include <stdio.h>
#include <string>






void bitwrite(int pass, char * fn)

FILE * fp;
fp = fopen(fn, "wb");
int k;
const void * kptr;
switch(pass)

case 0:
k = 0b11111111111111111111111111111111;
break;
case 1:
k = 0b10101010101010101010101010101010;
break;
case 2:
k = 0b01010101010101010101010101010101;
break;
case 3:
k = 0b11111111111111111111111111111111;
break;
case 4:
k = 0b10101010101010101010101010101010;
break;
case 5:
k = 0b01010101010101010101010101010101;
break;
case 6:
k = 0b00000000000000000000000000000000;
break;

fseek(fp, 0, SEEK_END);
off_t size = ftell(fp);
fseek(fp, 0, SEEK_SET);
for(int a = 0; a<sizeof(size);a++)

fseek(fp, a, SEEK_SET);
fwrite(&k, sizeof(int), 1, fp);


fclose(fp);


int main(int argc, char * argv)


if(argv == NULL)

printf("usage: ren file to be destroyed");
return 1;

for(int i=0;i<7;i++)

bitwrite(i, argv[1]);


printf("success!");

return 0;



This code needs to run efficiently as possible. I am at a loss as how to improve and fix errors. Currently, C++ ren.cpp -o ren runs without error, but gdb throws a sigseg error @fseek.







share|improve this question













I am an aspiring C++ programmer and I have been programming for a few years off and on but I don't have much usable knowledge. Right now I am working on filesystem safety so I decided to write an erasure (think BleachBit).



It needs to be run from terminal as such (root/ program filename.something) and needs to open the file in memory, get file size, write in raw binary format to each bit of file, close file,. This is a part where I am stuck. It needs to delete the (I am pretty sure it's some kind of pointer) object that represents
the file that the system stores by wiping it from memory.



ren.cpp:



#include <stdio.h>
#include <string>






void bitwrite(int pass, char * fn)

FILE * fp;
fp = fopen(fn, "wb");
int k;
const void * kptr;
switch(pass)

case 0:
k = 0b11111111111111111111111111111111;
break;
case 1:
k = 0b10101010101010101010101010101010;
break;
case 2:
k = 0b01010101010101010101010101010101;
break;
case 3:
k = 0b11111111111111111111111111111111;
break;
case 4:
k = 0b10101010101010101010101010101010;
break;
case 5:
k = 0b01010101010101010101010101010101;
break;
case 6:
k = 0b00000000000000000000000000000000;
break;

fseek(fp, 0, SEEK_END);
off_t size = ftell(fp);
fseek(fp, 0, SEEK_SET);
for(int a = 0; a<sizeof(size);a++)

fseek(fp, a, SEEK_SET);
fwrite(&k, sizeof(int), 1, fp);


fclose(fp);


int main(int argc, char * argv)


if(argv == NULL)

printf("usage: ren file to be destroyed");
return 1;

for(int i=0;i<7;i++)

bitwrite(i, argv[1]);


printf("success!");

return 0;



This code needs to run efficiently as possible. I am at a loss as how to improve and fix errors. Currently, C++ ren.cpp -o ren runs without error, but gdb throws a sigseg error @fseek.









share|improve this question












share|improve this question




share|improve this question








edited Jun 5 at 2:52









Jamal♦

30.1k11114225




30.1k11114225









asked Jun 5 at 0:17









user171218

11




11




closed as off-topic by Jamal♦ Jun 5 at 2:52


This question appears to be off-topic. The users who voted to close gave this specific reason:


  • "Code not implemented or not working as intended: Code Review is a community where programmers peer-review your working code to address issues such as security, maintainability, performance, and scalability. We require that the code be working correctly, to the best of the author's knowledge, before proceeding with a review." – Jamal
If this question can be reworded to fit the rules in the help center, please edit the question.




closed as off-topic by Jamal♦ Jun 5 at 2:52


This question appears to be off-topic. The users who voted to close gave this specific reason:


  • "Code not implemented or not working as intended: Code Review is a community where programmers peer-review your working code to address issues such as security, maintainability, performance, and scalability. We require that the code be working correctly, to the best of the author's knowledge, before proceeding with a review." – Jamal
If this question can be reworded to fit the rules in the help center, please edit the question.











  • You forgot to set fp before you call fseek. Did you mean for the result of the call to fopen to be set to fp?
    – jbapple
    Jun 5 at 0:25










  • i think so? im not fully familiar with file io
    – user171218
    Jun 5 at 0:34






  • 1




    Then there's the effects of caching by the OS., And the (remote) possibility that when you open the file later it might not be written to the same physical location on the disk. Either one will keep your scheme from working.
    – 1201ProgramAlarm
    Jun 5 at 0:36






  • 2




    The multi-pass thing does not help on modern drives. One pass of random data is sufficient. And it might not work at all, if sector remapping takes place!
    – JDługosz
    Jun 5 at 1:25






  • 1




    You can not do what you are trying to do from with file system calls (that is a layer of abstraction too far away). The file interface provided by the OS does not give you that much control of how it interacts with the blocks on the disk. You need to look at the block interface provided by your hardware.
    – Martin York
    Jun 5 at 15:06
















  • You forgot to set fp before you call fseek. Did you mean for the result of the call to fopen to be set to fp?
    – jbapple
    Jun 5 at 0:25










  • i think so? im not fully familiar with file io
    – user171218
    Jun 5 at 0:34






  • 1




    Then there's the effects of caching by the OS., And the (remote) possibility that when you open the file later it might not be written to the same physical location on the disk. Either one will keep your scheme from working.
    – 1201ProgramAlarm
    Jun 5 at 0:36






  • 2




    The multi-pass thing does not help on modern drives. One pass of random data is sufficient. And it might not work at all, if sector remapping takes place!
    – JDługosz
    Jun 5 at 1:25






  • 1




    You can not do what you are trying to do from with file system calls (that is a layer of abstraction too far away). The file interface provided by the OS does not give you that much control of how it interacts with the blocks on the disk. You need to look at the block interface provided by your hardware.
    – Martin York
    Jun 5 at 15:06















You forgot to set fp before you call fseek. Did you mean for the result of the call to fopen to be set to fp?
– jbapple
Jun 5 at 0:25




You forgot to set fp before you call fseek. Did you mean for the result of the call to fopen to be set to fp?
– jbapple
Jun 5 at 0:25












i think so? im not fully familiar with file io
– user171218
Jun 5 at 0:34




i think so? im not fully familiar with file io
– user171218
Jun 5 at 0:34




1




1




Then there's the effects of caching by the OS., And the (remote) possibility that when you open the file later it might not be written to the same physical location on the disk. Either one will keep your scheme from working.
– 1201ProgramAlarm
Jun 5 at 0:36




Then there's the effects of caching by the OS., And the (remote) possibility that when you open the file later it might not be written to the same physical location on the disk. Either one will keep your scheme from working.
– 1201ProgramAlarm
Jun 5 at 0:36




2




2




The multi-pass thing does not help on modern drives. One pass of random data is sufficient. And it might not work at all, if sector remapping takes place!
– JDługosz
Jun 5 at 1:25




The multi-pass thing does not help on modern drives. One pass of random data is sufficient. And it might not work at all, if sector remapping takes place!
– JDługosz
Jun 5 at 1:25




1




1




You can not do what you are trying to do from with file system calls (that is a layer of abstraction too far away). The file interface provided by the OS does not give you that much control of how it interacts with the blocks on the disk. You need to look at the block interface provided by your hardware.
– Martin York
Jun 5 at 15:06




You can not do what you are trying to do from with file system calls (that is a layer of abstraction too far away). The file interface provided by the OS does not give you that much control of how it interacts with the blocks on the disk. You need to look at the block interface provided by your hardware.
– Martin York
Jun 5 at 15:06










1 Answer
1






active

oldest

votes

















up vote
2
down vote













Instead of switch, just use an array.



k= pattern[pass];



Don’t use the C macro NULL for any purpose. Banish it from your memory!




The style in C++ is to put the * or & with the type, not the identifier. This is called out specifically near the beginning of Stroustrup’s first book, and is an intentional difference from C style.




Why are you including <string> when you do not use any? There is nothing at all from the C++ standard library here. I would think it was a C program.






share|improve this answer





















  • <string>is from my last program, can you drop a link to why null is bad? can you pass on info as to that book and to 'c style'?
    – user171218
    Jun 5 at 1:41










  • also i need to find an efficient way to unlink the file, truncate it, clear the sys cache and avoid sector remapping? if you have any advice on that please let me know.
    – user171218
    Jun 5 at 1:43










  • @user171218 not in this Stack. this is for code reviews.
    – JDługosz
    Jun 5 at 1:45










  • Please don't answer questions that are off-topic here. This encourages others to continue asking off-topic questions. Instead, you should vote to close.
    – Daniel
    Jun 5 at 5:50










  • @user171218 start with The Cpre Guidelines. I was saying write myclass* p; with the * hugging the type name.
    – JDługosz
    Jun 6 at 0:09

















1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes








up vote
2
down vote













Instead of switch, just use an array.



k= pattern[pass];



Don’t use the C macro NULL for any purpose. Banish it from your memory!




The style in C++ is to put the * or & with the type, not the identifier. This is called out specifically near the beginning of Stroustrup’s first book, and is an intentional difference from C style.




Why are you including <string> when you do not use any? There is nothing at all from the C++ standard library here. I would think it was a C program.






share|improve this answer





















  • <string>is from my last program, can you drop a link to why null is bad? can you pass on info as to that book and to 'c style'?
    – user171218
    Jun 5 at 1:41










  • also i need to find an efficient way to unlink the file, truncate it, clear the sys cache and avoid sector remapping? if you have any advice on that please let me know.
    – user171218
    Jun 5 at 1:43










  • @user171218 not in this Stack. this is for code reviews.
    – JDługosz
    Jun 5 at 1:45










  • Please don't answer questions that are off-topic here. This encourages others to continue asking off-topic questions. Instead, you should vote to close.
    – Daniel
    Jun 5 at 5:50










  • @user171218 start with The Cpre Guidelines. I was saying write myclass* p; with the * hugging the type name.
    – JDługosz
    Jun 6 at 0:09














up vote
2
down vote













Instead of switch, just use an array.



k= pattern[pass];



Don’t use the C macro NULL for any purpose. Banish it from your memory!




The style in C++ is to put the * or & with the type, not the identifier. This is called out specifically near the beginning of Stroustrup’s first book, and is an intentional difference from C style.




Why are you including <string> when you do not use any? There is nothing at all from the C++ standard library here. I would think it was a C program.






share|improve this answer





















  • <string>is from my last program, can you drop a link to why null is bad? can you pass on info as to that book and to 'c style'?
    – user171218
    Jun 5 at 1:41










  • also i need to find an efficient way to unlink the file, truncate it, clear the sys cache and avoid sector remapping? if you have any advice on that please let me know.
    – user171218
    Jun 5 at 1:43










  • @user171218 not in this Stack. this is for code reviews.
    – JDługosz
    Jun 5 at 1:45










  • Please don't answer questions that are off-topic here. This encourages others to continue asking off-topic questions. Instead, you should vote to close.
    – Daniel
    Jun 5 at 5:50










  • @user171218 start with The Cpre Guidelines. I was saying write myclass* p; with the * hugging the type name.
    – JDługosz
    Jun 6 at 0:09












up vote
2
down vote










up vote
2
down vote









Instead of switch, just use an array.



k= pattern[pass];



Don’t use the C macro NULL for any purpose. Banish it from your memory!




The style in C++ is to put the * or & with the type, not the identifier. This is called out specifically near the beginning of Stroustrup’s first book, and is an intentional difference from C style.




Why are you including <string> when you do not use any? There is nothing at all from the C++ standard library here. I would think it was a C program.






share|improve this answer













Instead of switch, just use an array.



k= pattern[pass];



Don’t use the C macro NULL for any purpose. Banish it from your memory!




The style in C++ is to put the * or & with the type, not the identifier. This is called out specifically near the beginning of Stroustrup’s first book, and is an intentional difference from C style.




Why are you including <string> when you do not use any? There is nothing at all from the C++ standard library here. I would think it was a C program.







share|improve this answer













share|improve this answer



share|improve this answer











answered Jun 5 at 1:33









JDługosz

5,047731




5,047731











  • <string>is from my last program, can you drop a link to why null is bad? can you pass on info as to that book and to 'c style'?
    – user171218
    Jun 5 at 1:41










  • also i need to find an efficient way to unlink the file, truncate it, clear the sys cache and avoid sector remapping? if you have any advice on that please let me know.
    – user171218
    Jun 5 at 1:43










  • @user171218 not in this Stack. this is for code reviews.
    – JDługosz
    Jun 5 at 1:45










  • Please don't answer questions that are off-topic here. This encourages others to continue asking off-topic questions. Instead, you should vote to close.
    – Daniel
    Jun 5 at 5:50










  • @user171218 start with The Cpre Guidelines. I was saying write myclass* p; with the * hugging the type name.
    – JDługosz
    Jun 6 at 0:09
















  • <string>is from my last program, can you drop a link to why null is bad? can you pass on info as to that book and to 'c style'?
    – user171218
    Jun 5 at 1:41










  • also i need to find an efficient way to unlink the file, truncate it, clear the sys cache and avoid sector remapping? if you have any advice on that please let me know.
    – user171218
    Jun 5 at 1:43










  • @user171218 not in this Stack. this is for code reviews.
    – JDługosz
    Jun 5 at 1:45










  • Please don't answer questions that are off-topic here. This encourages others to continue asking off-topic questions. Instead, you should vote to close.
    – Daniel
    Jun 5 at 5:50










  • @user171218 start with The Cpre Guidelines. I was saying write myclass* p; with the * hugging the type name.
    – JDługosz
    Jun 6 at 0:09















<string>is from my last program, can you drop a link to why null is bad? can you pass on info as to that book and to 'c style'?
– user171218
Jun 5 at 1:41




<string>is from my last program, can you drop a link to why null is bad? can you pass on info as to that book and to 'c style'?
– user171218
Jun 5 at 1:41












also i need to find an efficient way to unlink the file, truncate it, clear the sys cache and avoid sector remapping? if you have any advice on that please let me know.
– user171218
Jun 5 at 1:43




also i need to find an efficient way to unlink the file, truncate it, clear the sys cache and avoid sector remapping? if you have any advice on that please let me know.
– user171218
Jun 5 at 1:43












@user171218 not in this Stack. this is for code reviews.
– JDługosz
Jun 5 at 1:45




@user171218 not in this Stack. this is for code reviews.
– JDługosz
Jun 5 at 1:45












Please don't answer questions that are off-topic here. This encourages others to continue asking off-topic questions. Instead, you should vote to close.
– Daniel
Jun 5 at 5:50




Please don't answer questions that are off-topic here. This encourages others to continue asking off-topic questions. Instead, you should vote to close.
– Daniel
Jun 5 at 5:50












@user171218 start with The Cpre Guidelines. I was saying write myclass* p; with the * hugging the type name.
– JDługosz
Jun 6 at 0:09




@user171218 start with The Cpre Guidelines. I was saying write myclass* p; with the * hugging the type name.
– JDługosz
Jun 6 at 0:09


Popular posts from this blog

Greedy Best First Search implementation in Rust

Function to Return a JSON Like Objects Using VBA Collections and Arrays

C++11 CLH Lock Implementation