weitere portierte TAPs

[Maliboy]

Ach, der Quellcode ist IMHO nicht das Problem. Auf jeden Fall für Version 1.0 .

[FireBird]

das automatische fortsetzen macht der tms ja schon von selbst

so muß ich immer eine liste führen was unsere kids schon gesehn haben....

[FireBird]

Ach, der Quellcode ist IMHO nicht das Problem. Auf jeden Fall für Version 1.0 .

Es gibt keine Probleme, nur Herausforderungen. : Wie sage ich immer: alles ist möglich, es ist nur eine Frage des Zeitaufwands.

[Twilight]

jaja, ist mir eh klar

twilight

[Miq]

[quote="FireBird"]Ja, Jetsons AutoResume Datenbank.[/quote]

Könnte man die z.B. durch SQLite ersetzen? Es gibt daneben aber auch noch einige weitere "light weight" DB-libs.

[FireBird]

Könnte man die z.B. durch SQLite ersetzen? Es gibt daneben aber auch noch einige weitere "light weight" DB-libs.

Die paar Funktionen kann man sicher relativ schnell nachprogrammieren, ohne dass man eine grossartige Datenbank benötigt. Aber wenn ich aus einer PM an Maliboy zitieren darf:

Da es aber den beim TF5000 verwendeten StartCluster zum eindeutigen Identifizieren einer Datei auf Grund des geänderten Dateisystems nicht mehr gibt, muss man hier ein komplett neues Konzept erstellen.

[Miq]

[quote="FireBird"]Die paar Funktionen kann man sicher relativ schnell nachprogrammieren, ohne dass man eine grossartige Datenbank benötigt. Aber wenn ich aus einer PM an Maliboy zitieren darf:[/quote]

Ah... Das heißt, zur Unterscheidung werden keine "offiziellen" Filesystemdaten wie Name, Größe etc. benutzt? Benutzt der TMS ext3 als Filesystem?

[FireBird]

Ah... Das heißt, zur Unterscheidung werden keine "offiziellen" Filesystemdaten wie Name, Größe etc. benutzt?

Der StartCluster ist offizielles Topfield-API.

Benutzt der TMS ext3 als Filesystem?

JFS.

[Miq]

Würde ein schneller 96bit-Hash zur Unterscheidung reichen? Da hätte ich was in meiner Sammlung.

[FireBird]

[quote="Miq"]Würde ein schneller 96bit-Hash zur Unterscheidung reichen? Da hätte ich was in meiner Sammlung.[/quote]
Daraus könnte man sicher einen Ersatz für den StartCluster aufziehen.

[Maliboy]

Helft mir mal auf die Sprünge. Ich dachte, es geht um Auto Resume. Wofür den Start Cluster ?

[FireBird]

[quote="Maliboy"]Wofür den Start Cluster ?[/quote]
Das war eine eindeutige ID für eine bestimmte Datei und somit wunderbar als Key für eine DB zu gebrauchen.

[Twilight]

filer...

twilight

[Maliboy]

[quote="FireBird"]Das war eine eindeutige ID für eine bestimmte Datei und somit wunderbar als Key für eine DB zu gebrauchen.[/quote]

Ach so. Klaro. Dadurch konnte man die Datei verschieben und trotzdem blieb der Datenbank Eintrag erhalten.
In Perl gibt es unter Linux die Möglichkeit die Inode Nummer auszulesen. Ob es die bei JFS auch gibt und ob man da dran kommt?

[FireBird]

Danke für den Tipp:

Code: Alles auswählen

#include <sys/stat.h>

  struct stat statbuf;
  int status;

  status = lstat("/mnt/hd/ProgramFiles/iTiNa.tap", &statbuf);
  if(status == 0)
    TAP_PrintNet("inode = %d\n", statbuf.st_ino);

Das bedeutet aber nicht, dass ein 96bit-Hash-Algo unbrauchbar ist.

[Maliboy]

Schön zu sehen, das ich Programmierleie auch ab und an mal eine brauchbare Idee habe.

[ramibi]

Schon mal den Menüpunkt "Schnappschuss erstellen" ausprobiert

... nö

[Miq]

Das bedeutet aber nicht, dass ein 96bit-Hash-Algo unbrauchbar ist.

Willst haben? (es sind übrigens 3 32bit-Hashes parallel, MD5 und zwei andere)

[Harvey]

[quote="FireBird"]... iTiNa.tap ...[/quote]

Ui - gibt es zu so einem frühen Zeitpunkt schon etwas mehr oder weniger lauffähiges?

[ramibi]

Ui - gibt es zu so einem frühen Zeitpunkt schon etwas mehr oder weniger lauffähiges?

... neee