folgendes Statement zu continous files

CED999

Lieutenant
Registriert
Juni 2011
Beiträge
980
Hallo Leute,

wusste nicht wo genau ich das einstellen sollte, denke aber hier sind sicher einige, die bescheid wissen.

Running Image for DOS Without a Boot Disk
Introduction
Typically, to run Image for DOS (or a similar utility), you would create a bootable floppy diskette, USB flash drive, or CD/DVD disc, and then boot from that media. This article will describe a method for running Image for DOS (IFD) without the boot media. Instead, IFD will run from a boot file located on your hard drive.
Overview
Booting from a "boot file" is made possible by the free TeraByte Unlimited BOOTFILE (bootfile.exe) utility. BOOTFILE can configure the Master Boot Record (MBR) to boot from an NTFS, FAT, or FAT32 partition that is contained in a continuous file in an NTFS, FAT, or FAT32 partition. There are many different ways to configure a boot file, but in this example, we will configure it to run Image for DOS, and automatically reboot into the original operating system after IFD is closed. The TeraByte OS Deployment Tool (TBOSDT) will be used to create the boot file.

http://www.terabyteunlimited.com/howto/howto-ifd-bootfile.htm

Kann mir jemand erklären was dieses "continous file" bedeutet? habe auf google merkwürdigerweise nichts dazu gefunden. Ist das in einem der "Festplattenformate" einer der Virtuellen maschinen (wie .vmdk)?
 
Zuletzt bearbeitet:
Ich habe das so verstanden, dass es quasi eine Datei auf deiner Festplatte ist die beim Starten als virtuelle Festplatte zum Starten missbraucht werden kann. ( Also ähnlich einem virtuellen System bei dem die virtuelle Festplatte auch nur eine Datei auf deinem realen System ist )

Also das Tool richtet es ein, dass beim nächsten Booten in dieses System gebootet wird. Danach werden die gewünschten Änderungen gemacht und anschließend startet das System wieder in der ursprünglichen Konfiguration.

Ist das in einem der "Festplattenformate" einer der Virtuellen maschinen (wie .vmdk)?
Jepp das könnte man so sagen
 
Zuletzt bearbeitet:
Vielleicht ist continuous auch nur als einfaches Adjektiv gemeint? Wäre es ein Eigenname o.ä. wäre es wie Master Boot Record sicher nicht einfach klein geschrieben...

Evtl ist ja nur etwas wie "sich anschließend" gemeint ...
 
Zuletzt bearbeitet:
Continuous bezieht sich ja auf file, d.h. man startet von einer "zusammenhängende Datei" die auf der Festplatte mit "FAT, FAT32 oder NTFS" Partitionierung. Ich würde mich Suxxess Interpretation anschließen.
 
Halte ich für unwahrscheinlich, dann hätte man eher etwas wie "non fragmented" geschrieben. Abgesehen davon ist es für eine Anwendung funktionell irrelevant, ob die Datei fragmentiert ist oder nicht. Schließlich muss die Festplatte mit FAT, FAT32 oder NTFS formatiert sein und die kümmern sich darum, wo die Datei bei Fragmentation weiter geht.
 
Halte ich für unwahrscheinlich, dann hätte man eher etwas wie "non fragmented" geschrieben.

und was denkst was es dann heißt?

Für die Interpretation der anderen spricht doch folgendes: Auf einem Bios System hat der der Bootcode im MBR die Aufgabe den Bootsektor zu starten. D. h. für den Bootcode ist es vielleicth noch nicht vorgesehen sich z. B. an die MFT zu wenden um fraktionierte Dateien zu suchen?
 
Ja innerhalb eines rennenden OS ist es egal ob die Datei fragmentiert ist oder nicht weil das Dateisystem die Zugriffe regelt, aber es soll ja direkt von diesem File gebootet werden, also Zugriff wo noch gar kein OS da ist.

Anders gefragt: Wie weit muss ein Bootvorgang fortgeschritten sein, um nun mit fragmentierten Dateien umgehen zu können? Das kann ja wohl kaum vom allerersten Moment an sein.
Oder noch anders gefragt: Was auf einem 'normalen' Boot-Medium (und als sowas agiert das gefragte file ja quasi) darf fragemtiert sein? Zumindest den MBR kann ich mir schwer vorstellen. Und eine Fragmentierung an sensiblen Stellen würde man ja nur dann mit Garantie vermeiden, wenn das gesamte file an sich unfragmentiert ist.
 
Anders gefragt: Wie weit muss ein Bootvorgang fortgeschritten sein, um nun mit fragmentierten Dateien umgehen zu können? Das kann ja wohl kaum vom allerersten Moment an sein
.

das habe ich mich gerade auch gefragt.

Nebenbei das ist schon ein krasses Programm. Habe mir das mal installiert. Am Ende hast du einen Ordner in dem:

Ordner.PNG

liegt. Clickst Du auf die Batch, dann fährt windows runter, es startet das Programm und du kannst Images machen restores etc.

Diese .bin Datei, das ist die "Festplatte" oder?
 
Es muss gar nicht "weit fortgeschritten sein". Es funktioniert ja offensicht NUR mit FAT, FAT32 und NTFS d.h. die "Dateischicht" unterstützt diese drei Dateisysteme und MUSS deswegen auch in den jeweiligen Spezifikationen (z.B. Dateiindex) arbeiten. Könnte die Anwendung dies nicht, könntest du gar keine Datei zum Start spezifizieren, sondern müsstest Hardware Angaben (Zylinder, Sektor, jeweils Start und Ende) definieren.

Vom MBR kann man keine "Datei" booten, da der MBR nur das grobe Verzeichnis für die Festplatten und zugehörige Partitionen ist. Dort gibt es dann Details zu den einzelnen Partitionen, deren Dateisysteme, welche jeweils eigene Indexverzeichnise führen. Was sich für Dateien wo befindet weiß also erst das Dateisystem, die MBR Partitionstabelle weiß nur von wo sich physikalisch welche Art Dateisystem und Partition auf der HDD befindet.

Man könnte einen "Container" als eigene Partition oder ähnliches auf der HDD definieren (und entsprechend Partitionieren) und diese direkt in den MBR verlinkten, aber dann macht der komplette Kommentar mit unterstützten Dateisystemen und "continuous file" keinen Sinn, da eine Partition immer "continuous" ist (doppelte Benennung), jedoch niemals eine "file" (Widerspruch). Das kann also nicht die Erklärung sein.

Ich bitte euch noch einmal zu lesen, was dort steht:
Code:
BOOTFILE can configure the Master Boot Record (MBR) to boot from an NTFS, FAT, or FAT32 partition that is contained in a continuous file in an NTFS, FAT, or FAT32 partition.

Übersetzung:
BOOTFILE kann den Master Boot Record (MBR) so konfigurieren, dass sie eine FAT, FAT32 oder NTFS Partition innerhalb einer "continuous file" (zusammenhängenden Datei?, ich vermute im Sinne von "einer Datei" nicht im Sinne von "nicht fragmentiert") von einer FAT, FAT32 oder NTFS Partition starten können.

Die ".bin" Datei ist vermutlich die "Festplatte" von der zu startest.
 
Das Minibetriebssystem das gestartet wird muss so eine Art DOS-klon sein, weil des neben diesem Prog (IFD=Image for dos) noch IFL für linux gibt.

Wie funktioniert das jetzt eigentlich, dass ein Dos Programm ein NTFS Platte auslesen kann... Oder haben die die Unterstützung für NTFS dann einfach in ihr quasi Dos integegriert.
 
Sie eine Integration für NTFS (es gibt kommerzielle Treiber, auch für DOS Anwendungen) - evtl. nur eine Teilunterstützung,
 
Also ich lese das so: Dieses *.bin - file repräsentiert konzeptionell (bzw. das Programm gaukelt das dem MBR vor) beim Booten eine Partition (!! => und kein file!). Partitionen sind aber physisch nun immer "ein einziges ganzes", damit ist sowohl gemeint ein Stück, aber genauso "in einem durchgehend" -> was bei files aber genau unfragmentiert entspricht.

Daraus folgt:
-) diese vorgegaukelte Partition muss in genau ein einziges file reingepackt werden.
-) dieses File muss unfragmentiert sein (bzw. andere Eigenschaften einer Partition selbst aufweisen), um beim Booten eben als 'durchgehende' Partition wirken zu können.
Überleg doch: falls dem nicht so wäre müsste ja der Bootvorgang plötzlich mit 'fragmentierten Partitionen' umgehen können?

Womit continuous sowohl auf 'ein einziges' als auch 'unfragmentiertes' hinauslaufen würde. Ein file, das bei der Erstellung (wo es ja im Host-OS 'nur' ein normales file ist) dieselben layout-Anforderungen erfüllen muss wie eine Partition (als welche es beim Booten ausgelesen wird) per se. Für eine Partition mag 'continuous' selbstredend sein, beim file muss diese stringentere-als-normal Anforderung aber extra erwähnt werden.
 
Zurück
Oben