The above shows the correct result for an empty 2Gig USB flash drive. It's the same as I get when I re-format one with ext4. The 64k shown as "in use" is used by the ext4 filesystem itself.
I think clearing out /mnt/sdc1 with the flash drive removed fixed your problem. The mount point was actually not empty when your flash drive mounted to it. The mount points should always be kept empty when not in use.
When you right-click for the properties of a mount point (/mnt/sdb1, etc) it will show the volume used by the mounted device plus the static files in the mount point prior to mounting the device. This is a common mistake that happens in linux. People often accidentally put files in the directory that is the mount point without a device being mounted to it. The most often cause is people using symlinks to the mount point in scripts, and the script runs without the device actually being mounted.
/dev/zero, /dev/null, /dev/random, and /dev/urandom are character based psuedo devices.
https://en.wikipedia.org/wiki/Device_file
The "afo" utility was written in the C programming language, and the source code for the utility is in the first post of this thread.
afo - Aggressive file obliterator
-
april
This is essentially correct. Since I am unable to duplicate problem, all I can do is speculate.april wrote: I'm getting the impression its all a bit too hard and you are guessing some sorry.
I'd recommend the following to get you to where your script is tested and set up right:
1) Write the script initially using the "rm" command. This will delete the files normally without overwriting them, but that's ok for testing the script.
2) Once the script is debugged and working properly, overwrite the storage media with dd to zero it out, then reformat it.
3) Replace the "rm" command in the script with the "afo" command.
What this accomplishes is a separation of the script debugging from the confusion over whether "afo" is working right or not. If you get it working right with "rm" it should work the same way with "afo". THERE IS ONE IMPORTANT DIFFERENCE THOUGH: "afo" takes a LOT longer to run than "rm" because "afo" has to overwrite every byte in the file, while "rm" just removes the file name from the file system.
-
april
As I asked before ,are you able to do this in Precise 5.7.1 ? ,because I get it every time and have done it at least 20 times on 3 different file types (fat 32 ,ext 2 and ext4) of pre-formated usb sticks . So its very easy to duplicate.jafadmin wrote:This is essentially correct. Since I am unable to duplicate problem, all I can do is speculate.april wrote: I'm getting the impression its all a bit too hard and you are guessing some sorry.
I have not, however, tried it on any other distros, and there is always the possibility that my save file is corrupted somehow . I will eliminate that possibility soon by trying with a clean start.
Maybe this should give us a clue .Why would Precise 5.7.1 handle AFO differently?
The code is quite complex (well for me anyway). Did you write it or is it snippets borrowed?
Hi April,
Yes, 64Meg is the correct ext4 reserve area. I mistyped above. Feel free to try the same experiment with an ext2 FS and see the differences.
The "afo" utility was developed on Precise 5.7.1. All testing I have done with you here has been on Precise 5.7.1.
You have probably noticed by now that when you format a flash drive (or any drive, for that matter) from scratch that regardless of the format type the flash drives show some of the file system in use. This is reserved area for the file system's table to hold the names of directories and files. When a file is deleted, this is where the entry for that file is deleted from.
As with many of the other contributers on this puppy project, I have been a software engineer for many years, and contribute to linux because it makes me smile to do so.
The only complicated part of the "afo" source code is the recursion part. Recursion is necessary to traverse the directory levels.
https://en.wikipedia.org/wiki/Recursion
Yes, 64Meg is the correct ext4 reserve area. I mistyped above. Feel free to try the same experiment with an ext2 FS and see the differences.
The "afo" utility was developed on Precise 5.7.1. All testing I have done with you here has been on Precise 5.7.1.
You have probably noticed by now that when you format a flash drive (or any drive, for that matter) from scratch that regardless of the format type the flash drives show some of the file system in use. This is reserved area for the file system's table to hold the names of directories and files. When a file is deleted, this is where the entry for that file is deleted from.
As with many of the other contributers on this puppy project, I have been a software engineer for many years, and contribute to linux because it makes me smile to do so.
The only complicated part of the "afo" source code is the recursion part. Recursion is necessary to traverse the directory levels.
https://en.wikipedia.org/wiki/Recursion
-
april
OK so I just had an interesting experiment. I booted up Fatdog64 702 and installed AFO on it , then I created a clean usb stick with fat 32 file system and made sure it was clean .
Then I copied on half a dozen music files and hit it with afo
afo -c /mnt/sdc1/* . I was able to watch the files go but the first file remained ?
I then started again and hit it with
afo -c2 /mnt/sdc1/* and watched them go , this time all successfully gone
Did it again and started playing one of the songs before I hit it with afo and had a chuckle as the music went all garbled as I listened again with successful result overwriting twice but it took much much longer this way
Then I copied on half a dozen music files and hit it with afo
afo -c /mnt/sdc1/* . I was able to watch the files go but the first file remained ?
I then started again and hit it with
afo -c2 /mnt/sdc1/* and watched them go , this time all successfully gone
Did it again and started playing one of the songs before I hit it with afo and had a chuckle as the music went all garbled as I listened again with successful result overwriting twice but it took much much longer this way
Last edited by april on Wed 29 Jun 2016, 09:50, edited 2 times in total.
-
april
Mm OK but would that cause it to leave the first file intact? I was able to play the song after it was supposed to be deleted.
I think there is definitely a bug there and I am sure there is one in Precise but if you won't look we won't find them cause I don't know enough to fix it.
I'm sick of doing it over and over and it continues even with a clean boot of Precise
You are cherry picking the questions at best and leaving some unanswered while harping on the alternatives to AFO that I already know and do not wish to use yet .
Look at the above post . One would expect that using -c without a number would default to once only . If it doesn't it should. Spending the time to point this out to me is rather wasteful of your time and mine. Is that the reason the first file was not deleted ? You did not say that . I think not . I think there is a bug there.
I'm not going to get it solved wasting my time like this. I know its not quite doing what its supposed to and I am wondering why.
I think there is definitely a bug there and I am sure there is one in Precise but if you won't look we won't find them cause I don't know enough to fix it.
I'm sick of doing it over and over and it continues even with a clean boot of Precise
You are cherry picking the questions at best and leaving some unanswered while harping on the alternatives to AFO that I already know and do not wish to use yet .
Look at the above post . One would expect that using -c without a number would default to once only . If it doesn't it should. Spending the time to point this out to me is rather wasteful of your time and mine. Is that the reason the first file was not deleted ? You did not say that . I think not . I think there is a bug there.
I'm not going to get it solved wasting my time like this. I know its not quite doing what its supposed to and I am wondering why.
It's doing exactly what it's supposed to. You, however, are not.april wrote: I know its not quite doing what its supposed to and I am wondering why.
You are not supposed to add switches to a utilities' command line that expect a value, then not supply a value.
You're insisting that you should be able to misuse the utility but still get a satisfactory result.
(ever hoist a spinnaker when you're close hauled?)
I posted the source code for the utility in the first post of this thread with the intention that if anyone wanted to add or modify it to suit their particular needs they were free to do so. I encourage you do exactly that.
-
april
Clearly again cherry picking the questions . Narrowing on the one and ignoring the others .
Does that explain why the first file in Fatdog was still there intact?
Why I am questioning you this way is I'm doing the work to test this program that you have put out as your work . One assumes then you are the developer of that program . Two names are mentioned in the code for tinydir.h so I asume you have appropriated that function into your code as you are mentioned in the afo.c.
I take it then that you have written Clobber() and ClearDir(). One of them (or perhaps both I see as I was able to play the file afterwards) is responsible for missing the first file in the directory. Im looking now to see which.
If I am away for a while it is because being 30th June I have a stocktake to get organised here in Australia for tax time..
I am finding that you seem to be avoiding my direct questions by leaving them unanswered .
You invite use and discussion about the program here. If I find a bug and report it you avoid it like you don't want to know or you don't understand what "your" program does?
Don't see it as me having a shot at you please. If I'm putting in the time I expect to get the answers. Thats reasonable to you isn't it?
Does that explain why the first file in Fatdog was still there intact?
Why I am questioning you this way is I'm doing the work to test this program that you have put out as your work . One assumes then you are the developer of that program . Two names are mentioned in the code for tinydir.h so I asume you have appropriated that function into your code as you are mentioned in the afo.c.
I take it then that you have written Clobber() and ClearDir(). One of them (or perhaps both I see as I was able to play the file afterwards) is responsible for missing the first file in the directory. Im looking now to see which.
If I am away for a while it is because being 30th June I have a stocktake to get organised here in Australia for tax time..
I am finding that you seem to be avoiding my direct questions by leaving them unanswered .
You invite use and discussion about the program here. If I find a bug and report it you avoid it like you don't want to know or you don't understand what "your" program does?
Don't see it as me having a shot at you please. If I'm putting in the time I expect to get the answers. Thats reasonable to you isn't it?
-
april
Actually, it consumes the first filename as an integer. When atoi() fails to convert the first filename to a real integer, it fails by returning zero. When that happens, no file overwriting happens, but the remaining files get deleted anyway.april wrote:So if I use -c switch ,and don't put an integer where it expects one, the first "int passes" would have a null value , the second would be 1 not 0 ,wouldn't that explain it?
You can duplicate the behavior by setting "-c 0" which will cause afo to "delete only" all files in the filespec.
So, if 1 overwrite pass will suffice in your situation, the "-c" switch can be dispensed with.