FileSplitter v2.0 (15)

[himitsu]

[add]
die aktuelle (Test)Vesion + einges an Erklärung ist im Beitrag #22 zu finden
[/add]

Sooo, ich hab inzwischen vieles nochmas (teils Grundlegend) überarbeitet und weitere Features eingefügt.

Der FileSplitter kann (jetzt)

• es werden vom Programm (abgesehn vom optionalen Setup mit Explorerintegration) nirgendwo Daten gespeichert, also nichts mit Registry, INIs und was es sonst noch gibt
• Unicode (war doch wohl klar :engel: )
• von der Bediehnung her ist es immernoch mehr an eine Konsolenanwendung angelehnt und läßt sich auch von dieser aus ansteuern
  
  die Parameter: Programm starten und H für Hilfe auswählen oder über filesplitter -h ansehn
• Dateien zerlegen/splitten (wär ja blöd, wenn nicht)
• die Dateien wieder zusammenfügen (alternativ über eine Batchfile mit Windows-Copy)
• Neu: Zieldatei/-pfad kann jetzt frei gewählt werden.
  dennoch wird ein Name/Verzeichnis vorgeschlagen, welcher aus der Quelldatei erstellt wird.
• Neu: Dateien prüfen (Datei oder Dateiteile anhand der MD5-Datei)
• kann im Explorer-PopupMenü eingetragen werden
  wer in der alten Version einfach die EXE austautsch kann das schon jetzt oder dann für alle nach der Testphase
• Dateien jeder Größe sind möglich (solange es das Dateisystem unterstützt)
  also Dateien/Dateiteile über 2 GB (ich denk mal bis theoretisch fast 8 PB sollten für alle ausreichen)
• ja und die EXE ist wirklich so klein oder meint einer hier würden sich UPX und Co. noch lohnen
• Wenn das Programm von einer Konsole oder einer Batchfile aus aufgerufn wurde, dann gibt es auch dort einige Infos aus.
• und zur Sicherheit ist das Programm selbstprüfend - bei Defekt/Veränderungen bricht es ab
  (z.B. bei unvollständigem Download)
  http://www.delphipraxis.net/internal_redirect.php?t=123395
• Screenshots gibt's noch keine, aber es sind eh nur ganz einfache Dialoge, wo man hintereinander nach den nötigen Werten gefragt wird.
  
  und es sieht fast noch so aus wie in der Vorgängerversion
  http://www.delphipraxis.net/internal...t.php?t=100632

Im Anhang sind derzeit

• eine Betaversion (wird sich vermutlich nicht mehr viel dran ändern)
  diese ist auch nochmal einzeln angehängt
• eine Testbeta mit 'ner art Benchmark und wo immer das Consolenfenster erstellt/verwendet wird
• eine Scriptdatei über welche die "normale" Beta in derKonsole gestartet wird
• und 4 Screenies vom Abschlußdialog
  wo ich auch mal defekte Dateiteile übergeben hab (was steht im Dateinamen)
  und keine Sorge, die DOS-Box ist nicht immer vorhanden

Es wäre vorallem nett, wenn ihr das Programm ausgiebig testet
und vorallem mal prüft wie/ob das Teilen/Zusammenfügen über Netzlaufwerke läuft.


Es wird beim Splitten wenn möglich eine Batchfile [.bat] (nur wenn die Dateinamen DOS-kompatibel sind)
und zusätzlich eine Prüfdatei [.md5] angelegt.

In der MD5-Datei ist als erstes natürlich der MD5-Hash der Datei (sollte von anderen MD5-Testprogrammen hoffentlich verstanden werden) und anschließend sind noch weitere Informationen.

Die Batchfile [.bat] versucht zuerst den FileSplitter zu finden und ihm den Zusammenfügenauftrag zu übergeben
und falls die Suche erfolglos bleibt, dann werden die Dateiteile über COPY zusammengefügt.

Beim Zusammenfügen vergleicht der FileSplitter die erstellte Datei mit den Werten aus der MD5-Datei (wenn diese gefunden wurde) und gibt das Resultat aus (z.B. fehlende/defekte Dateiteile).


Information: in .md5>PartCheck stehen natürlich nur Informationen über den Urzustand der gesplitteten Datei.
(Dateigröße, Infos über die einzelnen Dateiteile und einige Hash's)



Tja, ansonsten ist nur das vermutlich weitgehenst Optimalste eingebaut:

• Umgehung der WindowsFileCache (NonBuffered-Read/Write)
• Overlapped Read/Write (mehr Zeit für interne Berechnungen)
• und wenn verfügbar AWE (Address Windowing Extension muß im Windows für Programme freigegeben sein)

mit viel Glück könnte das der wohl schnellste FileSplitter auf UserEbene sein.

Man kann da wohl sagen ich hab mich hier voll ausgetobt (im Moment fällt mir auch nichts mehr ein).
Was den UserMode(Windows) betrifft geht es kaum noch schneller (es si denn ich nehm den MD5-Teil raus)
und nur hierfür extra einen Dateisystemtreiber zu entwickeln wäre wohl übertrieben (nur weil man damit dann beliebig große Dateien innerhalb einer Partition in wenigen Millisekunden teilen/zusammenfügen könnte).

[MrKnogge]

Zitat von himitsu:

PS: bei -SEM wird nich nach der Größe gefragt, da dort der PartCheck-Abschnitt entfällt.

Stimmt, bei "-SEM" wird nicht danach gefragt, bei "-sem" aber schon

[himitsu]

O_O eigentlich sollt Groß-/Kleinschreibung egal sein

du hattest übrigens -SDM

sDm = Splitt + fortschritsDialog + nurMD5erstellen
sEm = Splitt + einfache MD5erstellen

[MrKnogge]

Oh sorry,ich meinte "-sdm". Da kommt die Auswahl wie ich denn gern geteilt hätte.

[himitsu]

Wie gesagt, damit legt man dort fest wieviele Teile man für die Fehlerprüfung möchte.

Dieser Wert legt dort nur fest über wieviele Teile der PartCheck läuft.
Aus diesem Grund wurde dort (ist nur bei -SM, -SDM und ähnlichem so) ein Wert vorgegeben.
die MD5-Datei belegt ja immer mindestens einen gewissen Platz auf der Festplatte und der Vorgabewert wurde so festgelegt, daß meistens nicht unnötig mehr Platz belegt, aber der bereits Reservierte habwegs ausgenutzt wird.

2 Teile = ein Defekt kann nur auf den Dateianfang (erste 50%) oder das Dateiende (letzte 50%) eingegrenzt werden.

mehr Teile dann entsprehend.

[MrKnogge]

Ahh, jetzt hab ich's kapiert.

[himitsu]

- inzwischen gibt's 'ne Meldung bei falschen Parametern (möglichst mit Angabe des falschen Zeichens)
- einige Strings wurden überarbeitet
- die Parameterbehandlung wurde geändert
(die Reinfolge der Zusatzparameter ist jetzt beliebig)
- an der fehlerprüfung arbeite ich noch ...

... danach lad ich dann 'ne Neue Version hoch


Aber hier ersmal ein Frage:
hab das Editfeld (Dateiname) in den Open-/SaveDialogen ja um Drag&Drop erweitert,
so daß man da z.B. aus'm Explorer den Namen reinziehen kann.

Jetzt war ich auf die Idee gekommen dieses, für eine einfachere Bediehnung, auf den ganzen Dialog auszuweiten, aber leider bekomm ich das Drag&Drop der Dateiliste (ListView) nicht weg.
Ein einfaches DragAcceptFiles(...,False) reicht leider nicht aus.

Nun ja, hab mal 2 Versionen im Anhang:
- einmal nur das Edit
- und das Andere über die gesamte Form (bis auf die ListView/Dateiliste)

Beim Zweiten muß man zwar nicht so genau "ziehlen", aber dank der Listview ist es doch bestimm verwirrender,
oder was meint ihr?

bzw, weiß jemand wie man die Dateiliste von der Drag&Drop-Fähigkeit befreien kann?
(ein Explorerhook ist vorhanden und ein Windowhook auf diese ListView wäre möglich)


Anhänge:
Programme Springen direkt zum OpenDialog ... danach diesen einfach per [Cancel] oder [X] shließen
(Param -v hartcodiert ... also selbst bei [OK] würde nichts gespeichert oder irgendwo verändert)
Zum Testen einfach Dateien/Verzeichnisse (beim Drag&Drop wird noch nichts geprüft) z.B. aus einen Explorer oder auch der Dateiliste/ListView in das "Editfeld" ziehen

[turboPASCAL]

Ist mir pers. etwas Umständlich mit den Parameterzeugs. Eine nette GUI wäre da nicht ganz
Unvorteilhaft. Deine Beschreibungen zu den Programmen ist etwas dünn, was mach ich jetzt mit
den Exec. ?

Aber Auseinandernehmen und Zusammenbasteln mach dein Tool.

[himitsu]

Die Beschreibung bau ich Stück für Stück auf. Hab hier auch schon seit einer Weile eine "große" Hilfedatei (aktuell RTF mit 2,5 MB dank der Bilder), aber diese ist noch für die alte Version ... kümmer mich halt erstmal mehr um das Programm bzw. die Funktionen und dieses kommt danach dran.

OK, eine GUI-Version könnte ich bestimmt noch erstellen, aber erstmal kümmer ich mich mal um die Funktionen
und so schlimm ist es doch garnicht ... vorallem im Zusammenhang mit der Explorerintegration, da bräuchte man im Grunde nur noch die SplitSize einzugeben und sonst ist eigentlich alles per Default vor-/festgelegt (Zieldatei bestätigen/ändern, SplitSize eingeben und fertig ... heißt die GUI wäre zum Großteil inaktiv)


Und ein Open-/Savedialog würde dort auch benötigt (nur daß man ihn in einer GUI erst aufrufen muß und hier kommt er sofort und nur da wo nötig)

[Add] MiniGUI-Vorschlag (Design noch änderbar)

[himitsu]

Bis zum update/veröffenlichung einer voll funktionsfähigen Version wird's noch etwas dauern

erstmal kämpf ich ja noch etwas hierran > mehrsprachige Resourcen nutzen
dann bastle ich mir grad 'nen Installer, um die alte Batchfile abzulösen.
und frühsetens mit Fertigstellung des Installers brin ich ein Final-Relase raus und dann auch weider mit Explorerintegration.


und noch eine Frage: hab mir ja den Opendialog um Drag&Drop erweitert ...
weiß zufällig jemand, wie man das Standard-Drag&Drop-Verhalten des FileList abschalten kann?

wenn ich das ganze Fenster als Ziel anlege, dann hat leider dieses Standardverhalten Vorrang
und da MS ja mal wieder an den IDs rumspielen könnte, ist auch des D&D für das Editfeld nicht ganz sicher.
(außerdem wär es schön, wenn des gesamte Fenster als Ziel diehnen könnte ... müßte man nicht unbedingt das Editfeld treffen)

derzeit hab ich es so implementiert, daß wenn das Edit nicht gefunden wird, das "ganze" Fenster mit D&D ausgestattet wird.


Dann hate ich die Steuerung per Parameter grundlegend überarbeitet ... jetzt ist unter anderem die reinfolge der Zusatzangaben im 1. Parameter egal.
Und zusätzlich wurde die Consolenausgabe erweitert.


Ja und da es viele unbedingt wollten .. hab ich eine zusammengefaßte GUI eingebaut (noch nicht fertig)
> wird aktuell über Paramter -g aufgerufen (bei Parametersteuerung dann einfach irgendwo ein G in den ersten Parameter einbauen)
!!! unferig: Dateiöffnendialoge, D&D und noch einiges Anderes fehlt noch
zusammen mit den alten Dialogen sollte das Programm aber soweit lauffähig sein (auch wenn noch einige Änderungen anstehen)


Wer die neue GUI mal sehn will > "FileSplitter.exe -g" in eine FileSplitter.bat reinschreiben.
(aber nicht wunder ... bei Aufruf per Batchfile öffnet sich ja ein Consolenfenster und der FileSplitter schreibt da rein)

[bitsetter]

Hallo,

wollte nur mal unauffällig darauf hinweisen, dass dein Programm nicht mehr Win98 unterstützt.
Konnte im 1. Beitrag kein Hinweis darauf finden.

Fehlermeldung: "verknüpft mit dem fehlenden Export-KERNEL32.DLL:FreeUserPhysicalPages."