Discussion :

[Hell]

Bonjour à tous,

J'utilise la classe Tfilestream pour lire et remplacer des données dans un fichier. J'aimerai insérer des octets au début d'un fichier, en fait je veux remplacer un header de 64 octets par un autre de 128 octets donc je pensais insérer 64 octets et remplacer les 64 suivants. Si j'utilise la méthode Write, ça me remplace uniquement les octets par des autres, ça n'insère rien et écrase des données que je veux conserver.

Comment faire?

Merci d'avance

[ShaiLeTroll]

L'insertion c'est le plus problématique, car cela implique de décaler tout le reste ...

Ouvre deux FileStream, un sur la source, l'autre sur la destination, puis génère ton entête dans le stream destination, puis ensuite, tu boucles bêtement pour copier la source dans la destination (fait le par un buffer de 64Ko par exemple, pour avoir une progression sans avoir trop de lenteur)

Ensuite, sauvegarde l'original ailleurs, et renomme le fichier de destination ...

[Hell]

Merci
J'avais pensé à cette méthode mais je m'étais dit qu'il y avait une autre classe faites pour les insertions.

A propos du buffer de 64 ko, je n'ai aucune idée de comment m'y prendre. Est ce qu'il faut que je crée une variable temporaire et que je concatene chaque octet lu et que j'écrive dès que j'en ai 65536 ?

[ShaiLeTroll]

Bon, l'idée est là, la syntaxe c'est pas tout à fait ça ... Donc tu lit, les 64Ko d'un coup, et tu les écrits d'un coup, tu as toutes les fonctions pour, et heureusement c'est nettement plus rapide en lecture DD et allocation mémoire des buffers que la concaténation ...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
var
  InStream: TFileStream;  
  OutStream: TFileStream;
  Header: array[0..127] of Byte; // Tu peux faire aussi un packed record de 128 octets, j'ai mis bcp d'exemple sur le forum à ce sujet
  Buffer: array[Word] of Byte;
begin
  BuildHeader(Header);
  OutStream.Write(Header, SizeOf(Header)); 

  InStream.Read(Buffer, SizeOf(Buffer)); // Peut-être un @Buffer...
  OutStream.Write(Buffer, SizeOf(Buffer)); 
end;

Un petit appel à ceux qui connaisse NTFS (darkvadr par exemple) pour voir si l'insertion de données en possible via une fragmentation du fichier ?

[Hell]

C'est carrément plus rapide avec un buffer, surtout sur un fichier volumineux. J'ai fait le test sur un fichier de 70 mo avec et sans buffer et je gagne plusieurs minutes avec le buffer
Merci beaucoup

[darkvadr]

Un petit appel à ceux qui connaisse NTFS (darkvadr par exemple) pour voir si l'insertion de données en possible via une fragmentation du fichier ?

Oulala, il y a longtemps que je n'ai rien posté. Ca crain...
Dire que je connais NTFS est un peu exagéré disons que mon ancien boulot faisait que j'étais obligé de m'y interesser.

Et ca fait plus d'un an que j'ai changé de job, il faudrait que je me replonge dedans, mais pour être honnête mon nouveau boss est un esclavagiste et je n'ai que peu de temps.

Si j'ai bien comprit l'idée qui se cache dans ton cerveau shaï voici schématiquement ce que tu voudrais réaliser:

soit un fichier représenté comme ca...

disons:

xxxxxxxxxxxxxx

et le données à insérer

yyyy

ou chaque x et chaque y est un octet.

Voici par exemple le resultat qu'on veut obtenir après insertion

xxxxxyyyyxxxxxxxxx

ce qui oblige a faire des décallages.

Mais mais dans ton cerveau aussi malade que le mien tu te dis sans doute

pourquoi ne pas l'écrire comme ca:

xxxxxxxxxxxxxxyyyy

et aller trafiquer la table d'alloc pour dire: Voici un fichier fragmenté!
et il faut le lire comme sur l'image jointe (par exemple et grosso modo)

mmmmmm.... pas simple du tout... mais réalisable... il faudrait que j'y réfléchisse.

Ce serait un hack intéressant... Comment utiliser un problème conceptuel (la fragmentation) pour optimiser une insertion...

[ShaiLeTroll]

Exactement, DarkVadr, les esprits malades se rencontrent ... mais c'était l'idée, après cela améliore l'insertion si le volume de données est important après la dite insertion, mais à voir si en lecture, si faire balader les têtes de lecture ne détériore pas trop les performances en faisant perdre très vite le gain de l'insertion, ...

Comment font les DB, je sais qu'en paradox, les insertions dans la clé primaire c'est la cata car justement ça décale car l'ordre physique c'est la clé primaire justement ... dans les autres DB, j'ignore comment c'est fait ... mais il me semble plus performant d'avoir un index que l'on met à jour qui indique la position des enregistrements (sauf si l'enreg est plus petit que la table d'index), ces derniers étant écrit dans un ordre peu important (surtout pour la problématique des VarChar ...),