PureBoard

So nun noch ein paar Updates

Update 0.8 -> 0.9

- Geschätzte Dauer (noch im beta stadium)
- Eventmanagment ausgebessert
- Abbruch Button

Update 0.9 -> 0.95

- Doppelte Passwortabfrage beim Verschlüsseln
- kb/s Anzeige (noch im beta stadium)

Update 0.95 -> 0.96

- Nullbyte Fehler beseitigt

Update 0.96 -> 0.97

- Speicherort kann nun festgelergt werden

Update 0.97 -> 0.98

- Neues Design
- Keine Messagerequester mehr

@AND51:
Wieso soll bei FileBufferSize(0) der Restmagnetismus fehlen?
So wie ich die Funktion verstehe cached sie bloß die PB-internen Schreibzugriffe, d.h. wenn ich jetzt WriteByte(blah) mache, werden die tatsächlichen Daten erst geschrieben wenn der Buffer voll ist um so z.b. bei Festplatten die Clusterausnutzung zu optimieren (es wird standardmäßig immer ein Block von 4096 Byte geschrieben)

Mit der Sicherheit von den überschriebenen Daten dürfte das wenig zu tun haben. Ist ja schließlich auch egal ob du mit deinem Bleistift langsam jeden Buchstaben einzeln schreibst, oder eben alle auf einmal

Sicher(er) wäre es die alte Datei jeweils mehrfach mit zufälligen Werten zu überschreiben. (Beispiel)

also das mit dem zufälligen werten überschreiben und dann löschen soll sicherer sein?

Hmm könnt ich ja noch hinzufügen..
so als extra

> Wieso soll bei FileBufferSize(0) der Restmagnetismus fehlen?
Weil bei FileBufferSize(0) alle Schreiboperationen tatsächlich auf die Disk getätigt werden. So steht es in der Hilfe. Und was gibt es besseres, als direkt auf die Disk zuschreiben, um die alte Datei zu überschreiben?

> Mit der Sicherheit von den überschriebenen Daten dürfte das wenig zu tun haben.
Wie ich bereits im Vorfeld sagte, propagiere ich hier keine 100%ige Sicherheit. Ich habe mir jegliche Irrtümer vorbehalten.

> Ist ja schließlich auch egal ob du mit deinem Bleistift langsam jeden Buchstaben einzeln schreibst, oder eben alle auf einmal
Ähm... Ich habe nicht von schnell/langsam gesprochen, ne? Sondern von doll aufdrücken oder nur leicht aufdrücken. Nur die Aufdrück-Stärke entspricht der Magnetfeldstärke der Festplatte. Die Schreibgeschwindigkeit hat nichts damit zu tun. Da verstehst du grad was falsch. AUßerdem war dies eh nur ein Beispiel, um klarzumachen, was (Rest-)Magnetismus ist, bzw. warum eine Datei trotz Löschung noch gelesen werden kann.

> Sicher(er) wäre es die alte Datei jeweils mehrfach mit zufälligen Werten zu überschreiben. (Beispiel)
Ich berufe mich hierbei auf einen Thread aus dem englischen Forum.
Dort bietet jemand 7 Algorithmen an, um eine Datei sicher zu löschen. Und das besondere: Er benutzt FileBufferSize(1024*1024) (1 MB)!
Wenn, dann ist ja wohl seines unsicherer, als meines. Er flusht den Buffer manuell durch aufrufen von FlushFileBuffers(). Bei meiner "Methode" wäre der Buffer, wie gesagt direkt ausgeschaltet, und alle Opertationen würden direkt auf die Disk geschrieben werden und das manuelle flushen entfällt.

Link: http://www.purebasic.fr/english/viewtop ... elete+file

AND51 hat geschrieben:> Wieso soll bei FileBufferSize(0) der Restmagnetismus fehlen?
Weil bei FileBufferSize(0) alle Schreiboperationen tatsächlich auf die Disk getätigt werden. So steht es in der Hilfe. Und was gibt es besseres, als direkt auf die Disk zuschreiben, um die alte Datei zu überschreiben?

Die Schreiboperationen werden so oder so auf Disk getätigt, die Frage ist nur nach welcher Zeit. Ein Ausschalten des Buffers führt lediglich dazu, dass alles sofort geschrieben wird, wodurch ein Programm womöglich langsamer werden kann.

AND51 hat geschrieben:> Mit der Sicherheit von den überschriebenen Daten dürfte das wenig zu tun haben.
Wie ich bereits im Vorfeld sagte, propagiere ich hier keine 100%ige Sicherheit. Ich habe mir jegliche Irrtümer vorbehalten.

Darum geht es doch auch garnicht. Mir ist klar dass nichts 100 pro safe ist. Du musst dich deswegen jetzt nicht an deinem Stolz angekratzt fühlen

AND51 hat geschrieben:> Ist ja schließlich auch egal ob du mit deinem Bleistift langsam jeden Buchstaben einzeln schreibst, oder eben alle auf einmal
Ähm... Ich habe nicht von schnell/langsam gesprochen, ne? Sondern von doll aufdrücken oder nur leicht aufdrücken. Nur die Aufdrück-Stärke entspricht der Magnetfeldstärke der Festplatte. Die Schreibgeschwindigkeit hat nichts damit zu tun. Da verstehst du grad was falsch. AUßerdem war dies eh nur ein Beispiel, um klarzumachen, was (Rest-)Magnetismus ist, bzw. warum eine Datei trotz Löschung noch gelesen werden kann.

Ich bezog mich ja auch nicht auf das was du geschrieben hast, sondern hab das Beispiel aufgegriffen und auf die Sache mit dem FileBuffer bezogen. Die "Aufdrück-Stärke" ist bei einer Festplatte wohl in jedem Fall gleich, mir ging es bloß um die Geschwindigkeit des programms und der Tatsache, dass die Daten beim Schreiben auf die Platte mit und ohne Buffer denselben "Abdruck" hinterlassen.

AND51 hat geschrieben:> Sicher(er) wäre es die alte Datei jeweils mehrfach mit zufälligen Werten zu überschreiben. (Beispiel)
Ich berufe mich hierbei auf einen Thread aus dem englischen Forum.
Dort bietet jemand 7 Algorithmen an, um eine Datei sicher zu löschen. Und das besondere: Er benutzt FileBufferSize(1024*1024) (1 MB)!
Wenn, dann ist ja wohl seines unsicherer, als meines. Er flusht den Buffer manuell durch aufrufen von FlushFileBuffers(). Bei meiner "Methode" wäre der Buffer, wie gesagt direkt ausgeschaltet, und alle Opertationen würden direkt auf die Disk geschrieben werden und das manuelle flushen entfällt.

Link: http://www.purebasic.fr/english/viewtop ... elete+file

Na dann, würde ich vorschlagen.. wenn das Ding hier wirklich seine Dateien sicher löschen will, sollte man so einen verwenden
Die Sache mit dem 1 MB Puffer und dem manuellen Flushen dient wohl dem Anschein nach dem Tuning der Dateizugriffe.

Naja, wenn ich hier komplett falsch liege lass ich mich gern korrigieren.

> Die Schreiboperationen werden so oder so auf Disk getätigt, die Frage ist nur nach welcher Zeit. Ein Ausschalten des Buffers führt lediglich dazu, dass alles sofort geschrieben wird
U beantwortest deine Frage schon selbst: Wann? Sofort!
In der HIlfe steht:

FileBufferSize() hat geschrieben:Wird 'Groesse' auf 0 gesetzt, dann wird das gesamte "Cachen" (Zwischenspeichern) ausgeschalten und alle Schreib-Operationen werden unmittelbar auf Disk geschrieben

Natürlich, wenn mehrere Programme gleichzeitg was wollen, dann werden sich die Daten bei der Festplatte "stauen". Dennoch wird alles möglichst sofort abgearbeitet. Letzendlich geht es auch nicht darum, wann geschrieben wird, sondern dass genau auf dieselbe Stelle geschrieben wird, an der die alte Datei liegt.

> wodurch ein Programm womöglich langsamer werden kann
Das habe ich auch schon im Vorfeld gesagt. Deshalb finde ich, sollte man den Benutzer fragen, ob er die alte Datei löschen möchte oder nicht, um Zeit zu sparen. Da Razor aber shcon eine restdauer-Anzeige eingebaut hat, finde ich es nicht schlimm, wenns etwas länger dauert. Hey, ich habe gerade den MD5-Hash einer 2 GB großen Datei ermittelt und das auch in NUR 56 Sekunden!!

> Du musst dich deswegen jetzt nicht an deinem Stolz angekratzt fühlen
Sorry. Ich möchte nicht rechthaberisch erscheinen. Falls es doch so ist, sorry nochmal.


> Die Sache mit dem 1 MB Puffer und dem manuellen Flushen dient wohl dem Anschein nach dem Tuning der Dateizugriffe.
Und wie gesagt, ich persönlich fänd es sicherer, den Buffer wenn dann schon ganz auszuschalten. Aber ich will niemandem meine Meinung aufzwingen. jetzt weißt du aber wenigstens, worauf meine Meinungen hier beruhen.

> Naja, wenn ich hier komplett falsch liege lass ich mich gern korrigieren.
Ich auch.

Unterlassen wir also mal die Diskussion in seinem Thread ok? *tätschel*

achwas ich muss ja was lernen ^^


So nun noch ein paar Updates

Update 0.8 -> 0.9

- Geschätzte Dauer (noch im beta stadium)
- Eventmanagment ausgebessert
- Abbruch Button

Update 0.9 -> 0.95

- Doppelte Passwortabfrage beim Verschlüsseln
- kb/s Anzeige (noch im beta stadium)

Update 0.95 -> 0.96

- Nullbyte Fehler beseitigt

Update 0.96 -> 0.97

- Speicherort kann nun festgelergt werden

Update 0.97 -> 0.98

- Neues Design
- Keine Messagerequester mehr

Update 0.98 -> 0.99

- Paar Bugfixes