Grote bestanden samenvoegen

[2_05]

Ik weet dat er genoeg manieren zijn om bestanden samen te voegen, bijvoorbeeld het dos-command:

quote: dos

copy /b *.ts Samengevoegd.ts

Nu ben ik op zoek naar een methode om dit te doen zonder een copy te hoeven maken.

Dit omdat dit met grote bestanden veel tijd kan besparen als niet alle data gekopieert hoeft te worden en ik de losse bestanden toch verwijder naderhand. Bovendien denk ik dat het mogelijk moet zijn. De software hoeft namelijk enkel de bestanden te laten lijken op fragmenten van een groot bestand en dan nog bepaalde tabellen van je systeem aanpassen. Na dit proces wordt het bestand dus gezien als een groot gefragmenteerd bestand. (en als ik het goed heb wordt de informatie over hoe die fragmenten bij elkaar horen bewaard in bepaalde tabellen van je systeem).

Ik heb echter nog geen enkel programma kunnen vinden die op deze manier bestanden aan elkaar maakt.

[Scyth]

2_05 schreef op dinsdag 30 januari 2007 @ 20:51:
Na dit proces wordt het bestand dus gezien als een groot gefragmenteerd bestand. (en als ik het goed heb wordt de informatie over hoe die fragmenten bij elkaar horen bewaard in bepaalde tabellen van je systeem).

Bedoel je nou dat je systeem bij moet houden over hoe jij verschillende bestanden in 1 groot bestand gooit? Want dat gaat het écht niet voor je doen. Je bestandstabellen worden gewoon geupdate, dwz. in dit geval alle referenties naar de losse bestanden worden gewist, en er word een nieuwe referentie aangemaakt voor je grote bestand.

Voor een goede oplossing hebben we meer informatie nodig:
- Moet het in een bepaalde volgorde in het uiteindelijk bestand komen
- Hoe groot zijn de losse bestanden
- Hoe is de naamgeving van de losse bestanden en die van het verzamelbestand.

(En misschien uit puur interesse: Waar ga je dit voor gebruiken!? )

edit:
Google vond deze apps voor je, gebaseerd op de informatie die ik uit je post kon halen:

http://www.jaist.ac.jp/~hoangle/filesj/index.html
http://www.freebyte.com/hjsplit/
http://www.peretek.com/sfj.php
http://www.snapfiles.com/download/dlsfj.html

En natuurlijk de Google search query

[ Voor 16% gewijzigd door Scyth op 30-01-2007 22:39 ]

[2_05]

Scyth schreef op dinsdag 30 januari 2007 @ 22:36:
[...]
- Moet het in een bepaalde volgorde in het uiteindelijk bestand komen
- Hoe groot zijn de losse bestanden
- Hoe is de naamgeving van de losse bestanden en die van het verzamelbestand.
(En misschien uit puur interesse: Waar ga je dit voor gebruiken!? )

Het gaat om ~100mb per bestand die genaamd zijn als naam0001.ts, naam0002.ts enz. Maar ze moeten dus 1 bestand worden zonder dat er een kopie gemaakt wordt. Bij de genoemde voorbeelden worden alle bestanden stuk voor stuk gekopieert naar een nieuw bestand en duurt het een minuut of 10 voordat ze samengevoegd zijn. Je hebt hierna zowel de losse bestanden als het resultaat bestand over. Ik zoek een programma dat simpelweg de bestandstabellen dusdanig aanpast dat je in windows nog maar 1 bestand ziet wat dan welliswaar uit losse fragmenten bestaat. (Dus fragmenten in de zin van als je gaat defragmenteren plakt die ze achter elkaar op de harde schijf, maar windows en ieder ander programma ziet het gewoon als 1 bestand)

Je bestandstabellen worden gewoon geupdate, dwz. in dit geval alle referenties naar de losse bestanden worden gewist, en er word een nieuwe referentie aangemaakt voor je grote bestand.

Dit is ook precies wat ik wil dat er gebeurt en ook weinig meer. Dus referenties wissen en een referentie aanmaken voor een groot bestand dat bestaat uit de losse fragmenten die oorspronkelijk naam0001.ts, naam0002.ts enz. voorstelden.

Dit omdat ik tijd wil besparen met het samenvoegen van al die GB's. En ik dacht, als een bestand gefragmenteerd op je HD kan staan, waarom dan niet gewoon losse bestanden die achter elkaar moeten komen omzetten in fragmenten die deel uit maken van een groot bestand. Dus waar het om draait is dat de harde schijf niet flink aan het ratelen hoeft, want dat betekend dat ie wel aan het kopieeren is.

Ik hoop dat het zo duidelijker is waar ik precies op doel, tientallen bestanen van 100mb binnen enkele seconden samengevoegd.

[Scyth]

2_05 schreef op dinsdag 30 januari 2007 @ 23:30:
Dus referenties wissen en een referentie aanmaken voor een groot bestand dat bestaat uit de losse fragmenten die oorspronkelijk naam0001.ts, naam0002.ts enz. voorstelden.

Naar mijn weten is dit niet mogelijk. Wat gebeurt er als je bijvoorbeeld in Windows het bestand verwijderd? Dan verwijder je 1 entry uit de tabel, maar er staan nog tientallen bestanden gewoon op de schijf. (Overigens is dit niet zo'n probleem bedenk ik me net, dit is ook de manier waarop Windows bestanden verwijderd; gewoon bestandstabel leegkieperen)

2_05 schreef op dinsdag 30 januari 2007 @ 23:30:
En ik dacht, als een bestand gefragmenteerd op je HD kan staan, waarom dan niet gewoon losse bestanden die achter elkaar moeten komen omzetten in fragmenten die deel uit maken van een groot bestand.

Interessant. Maar dit betekent dat daar per ongeluk niet al iets tussen de losse bestanden moet staan, daar komt bij dat 'defragmenteren' maar tot op een bepaalde hoogte effectief is.

2_05 schreef op dinsdag 30 januari 2007 @ 23:30:
Ik hoop dat het zo duidelijker is waar ik precies op doel, tientallen bestanen van 100mb binnen enkele seconden samengevoegd.

Duidelijk wel. Ik denk echter dat de oplossing echter verder weg is nu. Ik ben nog nooit een programma tegen gekomen wat de FS van Windows dusdanig voor de gek houdt dat ook Windows 't niet doorheeft (denk aan chkdsk enzo).

't dichtstbijzijnde wat ik kon vinden over wat jij wou is dit:
http://cpan.uwinnipeg.ca/...Raid/File/LinearRaid.html

En daar kan je al helemaal niets mee, ja.. of je moet je eigen filereader gaan schrijven

[downtime]

2_05 schreef op dinsdag 30 januari 2007 @ 20:51:
Ik weet dat er genoeg manieren zijn om bestanden samen te voegen, bijvoorbeeld het dos-command:

[...]

Nu ben ik op zoek naar een methode om dit te doen zonder een copy te hoeven maken.

De DOS oplossing is gewoon inefficient omdat het samenvoegen van 100 fragmenten betekent dat het eerste datafragment 100x gekopieerd wordt, het tweede 99 keer, het derde 98 keer, etc. Met een echt filesplitter/joiner programma gebeurd dit maar 1 keer en zal het veel sneller gaan.

Zoiets als dit dus:

code:

REM voorbeeldcode voor een te joinen bestand met 10 fragmenten.

COPY /B KLEIN1.AVI+KLEIN2.AVI GROOT.AVI
COPY /B GROOT.AVI+KLEIN3.AVI GROOT.AVI
COPY /B GROOT.AVI+KLEIN4.AVI GROOT.AVI
COPY /B GROOT.AVI+KLEIN5.AVI GROOT.AVI
COPY /B GROOT.AVI+KLEIN6.AVI GROOT.AVI
COPY /B GROOT.AVI+KLEIN7.AVI GROOT.AVI
COPY /B GROOT.AVI+KLEIN8.AVI GROOT.AVI
COPY /B GROOT.AVI+KLEIN9.AVI GROOT.AVI
COPY /B GROOT.AVI+KLEIN10.AVI GROOT.AVI

Zoals je ziet wordt het GROOT.AVI bestand hier 8x gelezen en 9x weer opgeslagen. Het wordt ook steeds groter en dus gaat elke kopieeropdracht steeds langzamer. Vreselijk inefficient vooral naarmate het aantal fragmenten groter is.

Dit omdat dit met grote bestanden veel tijd kan besparen als niet alle data gekopieert hoeft te worden en ik de losse bestanden toch verwijder naderhand. Bovendien denk ik dat het mogelijk moet zijn. De software hoeft namelijk enkel de bestanden te laten lijken op fragmenten van een groot bestand en dan nog bepaalde tabellen van je systeem aanpassen. Na dit proces wordt het bestand dus gezien als een groot gefragmenteerd bestand. (en als ik het goed heb wordt de informatie over hoe die fragmenten bij elkaar horen bewaard in bepaalde tabellen van je systeem).

Dat idee gaat volgens mij niet werken. Die fragmenten moeten namelijk allemaal precies even groot zijn als de grootte van een eenheid (cluster) van je filetabel (standaard 512 bytes voor NTFS als ik me goed herinner) en alleen het laatste fragment mag kleiner dan die 512 bytes zijn. Het FS houdt namelijk wel bij waar de fragmenten staan maar niet hoe groot ieder fragment is. Er wordt vanuit gegaan dat elk fragment, behalve het laatste, 512 bytes groot is.
Bovendien kan NTFS ook besluiten om hele kleine bestanden niet een eigen cluster te geven maar om die data direct in de MFT bij te houden. Dat scheelt weer wat clusters als je heel veel hele kleine bestanden hebt.

Daarnaast, als het al kon, dan zou je het niet willen. Om dit te bereiken zou een programma direct de Master File Table moeten beschrijven met alle risico op incompatibiliteit (NTFS wordt van versie tot versie op onderdelen aangepast) en bugs. Laat het schrijven naar de MFT maar lekker aan je OS over.

[ Voor 14% gewijzigd door downtime op 31-01-2007 13:02 ]

[2_05]

downtime schreef op woensdag 31 januari 2007 @ 12:56:
[...]
alleen het laatste fragment mag kleiner dan die 512 bytes zijn.

Dit zie ik idd wel als een belangrijke rede dat het niet zal gaan werken. De losse bestanden eindigen natuurlijk niet met precies een gevuld fragment van 512 bytes dus dan moet je zowieso alles bestanden gaan kopieeren.

[Caveman]

downtime schreef op woensdag 31 januari 2007 @ 12:56:
[...]

code:

REM voorbeeldcode voor een te joinen bestand met 10 fragmenten.

COPY /B KLEIN1.AVI+KLEIN2.AVI GROOT.AVI
COPY /B GROOT.AVI+KLEIN3.AVI GROOT.AVI
ect ect

Zoals je ziet wordt het GROOT.AVI bestand hier 8x gelezen en 9x weer opgeslagen. Het wordt ook steeds groter en dus gaat elke kopieeropdracht steeds langzamer. Vreselijk inefficient vooral naarmate het aantal fragmenten groter is.

Ik heb geen oplossing voor je vraag maar wat hierboven staat snap ik niet hoor... je kunt gewoon met "+" werken in het copy command dus copy /b bestand1 + bestand2 + ..... grootbestand. het hele verhaal dat het eerste bestand dan 10x gelezen wordt is dan onzin, op deze manier worden de bestanden aanelkaar "geregen"

[ Voor 14% gewijzigd door Caveman op 01-02-2007 17:37 ]