Delphi-PRAXiS
Seite 2 von 2     12   

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Programmieren allgemein (https://www.delphipraxis.net/40-programmieren-allgemein/)
-   -   Checken von offenen Files und doch kopieren (https://www.delphipraxis.net/72452-checken-von-offenen-files-und-doch-kopieren.html)

Luckie 6. Jul 2006 15:32

Re: Checken von offenen Files und doch kopieren
 
Und was macht das Programm jetzt? :gruebel:

BTW beendet es sich als nicht Administrator einfach. Um eine Partition physisch zu öffnen braucht man Administratorenrechte.

himitsu 6. Jul 2006 15:43

Re: Checken von offenen Files und doch kopieren
 
Im Moment nüschts, außer (alle) Cluster (heißen doch Cluster? ... also der Verbund mehrerer Sectoren zu einem größeren Bereich, weil sonst alle Programme von Sectoren reden/schreiben ... wobei bei mir die Sektoren alle 512 Byte groß sind und die Cluster zwischen 512 und 8KB, also 1 bis mehrere Sectorengroß sind und die Programme alle den größeren Bereich verwenden, also nichts mit Sectoren :gruebel: )

Es wird also das gesamte "Laufwerk" ausgelesen und das was drin ins in kleinen happen abgespeichert.
(bei mir war es halt so, daß bekannten die Datenrettungsprogramme nicht alles fanden und mit diesem kleinen Teil hab ich mir halt alles (war nur'n kleiner 128 MB-USB-Stick) ausgelesen und die "angeblich" nicht vorhandenen Dateien dann zusammengersucht/zusammengefügt.
Na mal gucken ... hatte heute Früh etwas Zeit, und da is schonmal ein Auswahldialog für Laufwerke (alle physischen und logischen ... laut MSDN sogar RAID-fähig) entstanden ... wenn der Rechner weiterhin so ausgelastet ist, dann werd ich noch'n bissl Zeit finden, für's Schreiben und im MSDN rumstöbern, weil was anderes kann man bei fast 100% CPU nicht machen -.-''

Mit viel Glück entsteht so nochein Datenrettungsprogramm, was die Funktionen, welche ich bei den anderen Getesteten verißt hab :mrgreen:


[Edit]
Das mit den AdminRechten weiß ich ... ich hatte Adminrechte und wollte schnelle Ergebnise (also meine Dateien schnell zurück und so ist es auch geproggt ... also ohne großartige Fehleranalyse/-behandlung ... aber wenn ich es weiterentwickle, dann wird sich da bestimmt noch was ändern :zwinker:
Jetzt sind ja meine Dateien da, ich kann den Stick wieder verwenden ... hab also genug Zeit um so einige Lücken zu füllen :angel:

Go2EITS 6. Jul 2006 15:52

Re: Checken von offenen Files und doch kopieren
 
Hi, Himitsu,
prima, dass Du noch mal nachgesehen hast und den Sourcecode online gestellt hast.
Ich werde mir das ganze am Wochenende in Ruhe ansehen. Bin gespannt wie es weiter geht.
Bin ja mit WINCLEAN beschäftigt, wie Du gesehen hast.

Nachtrag:
Kann es sein, dass FAT32 nicht unterstützt wird?

CU :hi:
GO2EITS

Luckie 6. Jul 2006 23:11

Re: Checken von offenen Files und doch kopieren
 
Zitat:

Zitat von Go2EITS
Kann es sein, dass FAT32 nicht unterstützt wird?

Oder kein Windows < NT.

himitsu 7. Jul 2006 11:48

Re: Checken von offenen Files und doch kopieren
 
Also ich hab es hier mit UDF/CDFS, FAT und IFS(NTFS) laufen lassen ... ohne Probleme, aber kein Winder, denn im Moment wird dass Dateisystem eh "übersehn" ... es werden sozusagen die RAW-Daten ausgelesen.

Und wenn ich nichts übersehn hab, dann sollte es eigentlich bis runter zu Win98 laufen? :gruebel:

Wo ich jetzt am "rumspielen" bin, da sind einige Funktionen, wo's MSDN/PSDK was von Win2000Pro redet Gibt's da wirklich so große Unterschiede zwischen Professional und NichtPro? ... also was die vorhandenen WinAPI's angeht?
Also ich könnte nochmal nachsehn, ob nicht doch einer der Befehle erst ab Win2000(Pro) geht, aber sonst ist doch eigenlich nicht viel in dem Code drin, was Problemchen machen sollt.


PS: was das "einfach" Abstürzen angeht ... PC-Recovery ist bei mir unter NichtAdminRechten auch einfach so verschwunden und das ist doch wohl ein "ProfiTool", im Vergleich zu meinem 15-Minuten-NichtVielNachgedachtProjekt.


[add]
Also jetzt die FAT/FNFS...-Informationen auszuwerten, dat wäre natürlich der nächste Schritt ... bei größeren Platten kann das Speichern allerinforationen schon recht viel Platz verbrauchen.
- so ein/zwei Prozent mehr für's Dateisystem (jeder Block/Datei ein Eintrag)
- wenn die Clustergrößen nicht überenstimmen steigt der Verbrauch nochmal teilweise schon extrem an
(z.B. braucht 1 GB mit 512 B-Clustern schonmal 8 GB auf 'ner Platte mit 4 KB-Clustern)
- es werden auch ungenutzte Bereiche gespeichert
- und dann werden die Dateieninhalte ja och ohne Ordnerstrucktur und in "kleinen" Happen ausgelesen/gespeichert

da wäre es natürlich besser, wenn jetzt der Inhalt noch ausgewertet und wieder in 'nem Dateisystem zusammengeführt würde (so wie es die anderen Datenrettungsprogramme ja auch schon versuchen).


Alle Zeitangaben in WEZ +1. Es ist jetzt 05:57 Uhr.
Seite 2 von 2     12   

Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz