Question: Mount a folder as a drive (in ram)
#1
Posted 03 February 2012 - 04:43 PM
Is there a way to mount a folder (say, on CDRom) as a drive, in ram.
And for example have this folder appear, from a Dos image, as a drive.
The goal, being to have easy access to the files of the folder while in windows,
not stored in an Iso.
In Grub4dos, btw.
#2
Posted 03 February 2012 - 04:46 PM
#3
Posted 03 February 2012 - 04:59 PM
Yep. Under Dos. Either MsDos7.1, or Freedos. Mostly use Msdos7.1, though, as Dos.
And yep, to avoid driver.
Grub4dos>load folder as hd32, boot Dos image.
edit: yeah, 'booted from' an image.
#4
Posted 03 February 2012 - 05:11 PM
But here what I think might help achive my goal,
idea:
Like Dos Xmsdsk.
And like Chenall's copy/fat with grub4dos.
#5
Posted 03 February 2012 - 05:12 PM
Check this:
http://reboot.pro/9916/
It may contain (or completely fail to) something you could use.
Wonko
#6
Posted 03 February 2012 - 05:18 PM
1 what do you boot to grub4dos from - the CD you want to map as another drive, or some other device?
2 Could this 'CD' that you want to access from DOS be an ISO file (e.g. boot from USB drive or internal hdd, map iso as drive, boot to DOS image)
#7
Posted 04 February 2012 - 11:27 AM
Sorry, 2 more Q's -
1 what do you boot to grub4dos from - the CD you want to map as another drive, or some other device?
2 Could this 'CD' that you want to access from DOS be an ISO file (e.g. boot from USB drive or internal hdd, map iso as drive, boot to DOS image)
Hi Steve,
Sorry, I'm in an internet caf, so I'm not too often about.
1. Boot off CD. For eg, Grldr CD. Or Can be from grub floppy from HD, or grub Usb Drive (fat). For the scenario let's focus on "From CD".
On the same CD there might be a Dos image, and a folder with utilities.
2. No, an actual drive. An actual storage CD.
xmsdsk: I don't mean using Xmsdsk from grub, nor from Dos. Just the simplicity.Let's be more precise.
But here what I think might help achive my goal,
idea:
Like Dos Xmsdsk.
And like Chenall's copy/fat with grub4dos.
This might just be done by mapping --mem an area in Ram. Using offsets.
Chenall's copy/Fat, I think can only copy to root of drive. I assume it can copy a file from its path.
Hi Wonko
Hmmm.
Check this:
http://reboot.pro/9916/
It may contain (or completely fail to) something you could use.
Yeah, I like the idea.
I was thinking about something similar, a while back, not using isos though.
An ntldr topic about the copy mechanism, to boot images directly (from drive, not in RAM).
I was thinking about booting images from their offset addresses using a "custom MBR.
Coming back to this here topic, and also thinking of the link you gave, would there be a tool to get the offset of a file on
a drive, ie offset of a (contiguous) img. ?
Otherwise, I could have the folder zipped, copy the zip to a map --mem (offsetxxx) drive, and unzip to another ram-drive.
Zip being more 'common' than iso (in everyday use).
I like the
copy /b isohdr + floppy.img = floppy.iso. (in link)
#8
Posted 04 February 2012 - 01:10 PM
For FAT it is relatively easy to read the FAT, but you may find something useful here:Coming back to this here topic, and also thinking of the link you gave, would there be a tool to get the offset of a file on
a drive, ie offset of a (contiguous) img. ?
http://www.partition...m/utilities.htm
For NTFS see here:
http://reboot.pro/15086/page__st__25
For ISO/CDFS, see here:
http://reboot.pro/12406/
Wonko
#9
Posted 06 February 2012 - 02:27 PM
Before I go any further, is there a way from grub4dos to map --mem a number of cluster starting at an offset, which are resident on a drive?
For the moment focusing on a fat Fs.
Perticularlychainloader
grub> help chainloader
chainloader: chainloader [--force] [--load-segment=LS] [--load offset=LO]
[--load-length=LL] [--skip-length=SL] [--boot-cs=CS] [--boot-ip=IP]
[--ebx=EBX] [--edx=EDX] [--sdi] [--disable-a20] FILE
Load the chain-loader FILE. If --force is specified, then load it
forcibly, whether the boot loader signature is present or not. LS:LO
specifies the load address other than 0000:7C00. LL specifies the
length of the boot image(between 512 and 640k). CS:IP specifies the
address where the boot image will gain control. EBX/EDX specifies the
EBX/EDX register value when the boot image gets control. Use --sdi if
FILE is a System Deployment Image, which is of the Windows XP RAM boot
file format. Use --disable-a20 if you wish to turn off A20 when
transferring control to the boot image. SL specifies length in bytes at
the beginning of the image to be skipped when loading.
andLL specifies the
length of the boot image(between 512 and 640k).
SL specifies length in bytes at
the beginning of the image to be skipped when loading.
Thanks
#10
Posted 06 February 2012 - 03:31 PM
Compare http://reboot.pro/9916/is there a way from grub4dos to map --mem a number of cluster starting at an offset, which are resident on a drive?
map --mem (hd0,0)123+1000 (hd32)
#11
Posted 06 February 2012 - 03:37 PM
In the thread you were already pointed to:
http://reboot.pro/9916/
here:
http://reboot.pro/9916/page__st__26
and following.
When you write (example):
map --mem (hd0) (hd1)what you are actually issuing is:
map --mem (hd0) <OFFSET=0>+<length=whole HD0 size> (hd1)
The example cdob just posted means "map into memory 1000 sectors starting at offset 123 on first hard disk's first partition as hard disk 32"
map ( with -mem or otherwise) has nothing to do with chainloader
Wonko
- betrand likes this
#12
Posted 06 February 2012 - 07:46 PM
andIn the thread you were already pointed to
Compare http://reboot.pro/9916/
And
map ( with -mem or otherwise) has nothing to do with chainloader ../public/style_emoticons/default/dubbio.gif
Hehe, thanks.
Grrwish I had more time! (I will blame it on that!)
#13
Posted 06 February 2012 - 07:54 PM
What is the smallest size for a Fat32 image? Using the VERY GOOD Mbrbatch Mkimg!
I did 20M, fat32format.exe (48kb)(google):"too smaall".
And the Xp fat format, what fat is it?
And the winimage Win95 and Dos622?
Thanks.
#14
Posted 06 February 2012 - 10:15 PM
For the tests, I need to make a small Fat32 drive. I wanna go fat32, even though my main machine can't format fat32(XP).
What is the smallest size for a Fat32 image? Using the VERY GOOD Mbrbatch Mkimg!
I did 20M, fat32format.exe (48kb)(google):"too smaall".
And the Xp fat format, what fat is it?
And the winimage Win95 and Dos622?
Thanks.
WHICH in the above are:
- questions
- statements
- random guesses
- nonsense
??
Please take some time in deciding which is which and try posting again, also, unlike telegrams, you don't pay a fee per word, try writing full sentences with a subject, a verb, an object, etc., please.
Generally speaking, you first learn about the characteristics, specifications and features (and drawbacks) of various filesystems, THEN you decide which one may be more suitable to your project.
You seem to have chosen FAT32 because it "sounds" better in French (and in Urdu ) than "NTFS" or"FAT16", before having even the faintest idea which are their features.
Wonko
#15
Posted 07 February 2012 - 12:36 PM
Maybe I should post on Twitter, @reboot.
Especially
, that would fit!I did 20M, fat32format.exe (48kb)(google):"too smaall".
Ok,
I settled for Fat32, cause it sounds cool.
I also decided on it because it sounds more common, on Usb drives, or as alternative to NtFS.
I didn't choose NtFS for its proprietary FS, and the write delay (watever it's called).
I chose Fat32 rather than FAT12, 16, for the use of Msdos7.1. ( I thought it 'prefered' Fat32).
I also chose Fat32 because I had to choose one.
And, also, Fat 16 (eg Freedos) being less common. But a question being, why is Fat12 used? I mean, what for?
Xp bootfloppy, I think, is Fat12? You don't have to answer, they're just questions one might ask.
(If I settle for One format for the test, I'll be happy enough)
Thus, probably all
.random guesses
I shall, I think, settle for the fat xp uses to format a drive.
At the moment, though, I am just wondering, really,
if I need that much for the test:
A question, When one uses a map --mem
map --mem (hd0) + (hd1)would the FAT (File Allocation Table) be recreated?
Like Grub4dos recreating, I think, a Mbr based on HD when mapping, would it recreate the files' 'database'?
Thanks
Edit, btw, for clarity, and for laughs,
means: I did a 20M image, tried to format it with Fat32format.exe which I found on Google (or'you can google it if you want'),I did 20M, fat32format.exe (48kb)(google):"too smaall".
it's 48.0kb. But the program said, "the drive is too small for Fat32".
#16
Posted 07 February 2012 - 01:17 PM
And this is of course because you did not document yourself BEFORE choosing FAT32.means: I did a 20M image, tried to format it with Fat32format.exe which I found on Google (or'you can google it if you want'),
it's 48.0kb. But the program said, "the drive is too small for Fat32".
http://technet.micro...y/cc940351.aspx
http://www.pcguide.c...artSizes-c.html
BTW, if the intended use is XP (or later) AND USB stick, AND size < 1 or 2 Gb it is the most foolish choice you could make.
http://www.msfn.org/...d-on-usb-stick/
OT, but not much, FAT12 size limit is NOT really-really 16,736,256 bytes on recent MS OS:
http://www.msfn.org/...oppy-emulation/
http://www.msfn.org/...d-their-images/
When you do:
map --mem (hd0) (hd1)(NO + sign in the middle) you copy INTEGRALLY (hd0) to memory and map it in BIOS as (hd1) or second hard disk.
Obviously INTEGRALLY includes the FAT table(s).
Wonko
#17
Posted 07 February 2012 - 07:27 PM
About the Fat, Reading.
About the
,A question, When one uses a map --mem
map --mem (hd0) + (hd1)
would the FAT (File Allocation Table) be recreated?
TYPO!
Double typo too .
What was meant was
map --mem (hd0) + (hd1)dunno HOW that + from there got to (hd0) + (hd1). ??
And it is not even what I meant .
Re. When one [code=auto:0]map --mem +if the offset start and length define the location of a folder/file on a drive, will this folder file appear in the mapped drive?IE, would Grub4dos recreate a FAT?Was the question I was asking, before re-reading the Grub4dos map --mem a drive, recreates a Mbr based on partition table.
I basically thought Grub4dos would, understand ,'hmm this seems to be be a file, let's tell the user there is a file there'.If mapping a disk image of a partition without a MBR to memory, it can be mapped as a (hd) device as the MBR will be created within Grub4dos - based on the partition data.
But, knowing it probably won't, I see approx the next stage. If I can be @rsed, that is.
Thanks.
#18
Posted 07 February 2012 - 10:31 PM
No, Grub4dos dosn't recreate a FAT. It uses a existing FAT at mapping.would Grub4dos recreate a FAT?
Yes, a partition table entry is created, if it's necessary.recreates a Mbr based on partition table.
Chenall created a FAT module to manipulate files.
http://chenall.net/post/grub4dos_fat/
DMPS is a example http://code.google.c.../downloads/list
Idea:
create a disk in RAM, format as FAT, copy files to this disk.
No, I don't have a working example myself.
#19
Posted 07 February 2012 - 10:55 PM
You are still vey confused.The general syntax is:And it is not even what I meant .
Re. When one [code=auto:0]map --mem +if the offset start and length define the location of a folder/file on a drive, will this folder file appear in the mapped drive?IE, would Grub4dos recreate a FAT?Was the question I was asking, before re-reading the Grub4dos map --mem a drive, recreates a Mbr based on partition table.I basically thought Grub4dos would, understand ,'hmm this seems to be be a file, let's tell the user there is a file there'.But, knowing it probably won't, I see approx the next stage. If I can be @rsed, that is.
map --mem <source> <target>
ormap --mem (hd0) (hd31)
will simply COPY the source to memory AND map the the memory area where the source was copied as target, because BOTH source and target are the SAME "kind of objects" i.e., respectively a WHOLE hard disk or a hard disk image as source and a WHOLE hard disk as target. (each one has a MBR as first sector)map --mem /mydisk.img (hd31)
ormap --mem (fd0) (fd1)
behaves the same, because source and target are the same kind of objects (floppy disk or floppy disk images, each one has a PBR as first sector)map --mem (hd0,0) (fd1)There is a SPECIAL case which is:map (hd0,0)+1 (fd0)Check against README_GRUB4DOS:map --mem /myfloppy.ima (fd1)
which still behaves the same, because source and target are the same kind of object (floppy/superfloppy or Disk partition/volume - each one has a PBR as first sector)And another SPECIAL case which is:map --in-situ (hd0,4)+1 (hd31)see:Emulates HD partition C: as floppy drive A: and boot win98 from C: map --read-only (hd0,0)+1 (fd0) chainloader (hd0,0)+1 rootnoverify (hd0) bootIn the above example, (hd0,0) is drive C: with win98 on it. After win98boot complete, you will find that A: contains all files of C:, and ifyou delete files in A:, the files in C: will also disappear.At the map command line, the notation (hdm,n)+1 is interpreted torepresent the whole partition (hdm,n), not just the first sector of thepartition.
In this case source's first sector is a PBR BUT target first sector must be a MBR, which is then simulated by grub4dos.NO filesystem (not "FAT", FAT table(s) is/are part of the filesystem, that includes bootsector/PBR, reserved sectors, FAT(s) and in the case of FAT12/16, reserved space for ROOT entries) is created or harmed in these processes.********************************************************************************* About the new map option --in-situ *********************************************************************************--in-situ is used with hard drive images or hardrive partitions. With anin-situ map, we can typically use a logical partition as a primary partition.In-situ map is a whole drive map. It only virtualize the partition table andthe number of hidden sectors in the BPB of the DOS Boot Record.While disk emulation may encounter various problems with win9x, the in-situ mapworks fine with win9x.Note that --in-situ will not change the real partition table.Example:map --in-situ (hd0,4)+1 (hd0)
Wonko
#20
Posted 08 February 2012 - 12:29 PM
, This is driving me crazy! Each time I paste something in codebox, it comes out jumbled.You are still vey confused.
?When one map --mem +
Should've been
and
[s]map --mem (hd0) + (hd1)[/s]see next post. Is that possible?
@Wonko, yeah, source-target, I know. Thanks for wanting to clear it though. The above I hope explains what I meant.
@Cdob,
Yeah, I was going to ask, at some point, if creating an empty ramdrive with grub4dos was possible -out of the box.Idea:
create a disk in RAM, format as FAT, copy files to this disk.
No, I don't have a working example myself.
Thanks, & thanks for the links. I'd already seen the Fat copy tool,
Chenall's copy/Fat, I think can only copy to root of drive. I assume it can copy a file from its path.
Otherwise, I could have the folder zipped, copy the zip to a map --mem (offsetxxx) drive, and unzip to another ram-drive.
Zip being more 'common' than iso (in everyday use).
No, I don't have a working example myself.
, always good to see an unknown Iso.Dpms
@wonko,
, mhm! interesting. Interesting name, mostly, for me. "Sounds cool!"--in-situ
SO. Do you guys know if it's possible to create a blank formatted (or not) drive out of the box with Grub4dos?
By saying map this area of memory as say, floppy, CHS, FAT FS.
But the main idea being.
For the test:
1 container drive image. (hd-like)
1 Dos boot floppy
1 bootsector and FAT(.bin, .file, .whatever) [edit: of a second floppy]
After that the files of a second floppy (whose bootsector is the latter) are on the main drive image. The files are in the same order, an Hex-copy.
The floppy images must be same FS as main drive, to, I assume, avoid overlapping FSs.
The FAT of the main drive would list the files of second floppy, as well as a Bootsector and fat. bin.
The files of the floppy are now accessible from windows.
Grub4dos would have to map the offsets from bootsectorfat.bin to end of last file (on main drive), and map thae length as a drive.
Therefore we have a bs, a FAT, and files. In RAM.
It looks more like a proof of concept. Might be useful.
Fun.
Ok, see yas.
#21
Posted 08 February 2012 - 12:49 PM
map --mem (hd0) + (hd1)NO!
map --mem (hd0) offset= start of BSsandFAT.bin length=length of a drive, floppy for eg. (fd0)
#22
Posted 08 February 2012 - 12:55 PM
You cannot come back asking the same question that has been answered to SEVERAL times in this same thread.
is completely ABSURD.map --mem (hd0) <OFFSET=start of a
file/folder>+<length offilefolder> (hd1)
will have as result:map --mem (hd0) <OFFSET=start of a file
/folder>+<length of file> (hd1)
to COPY the file to memory and to map the file as second hard disk.
IF (and only IF) the source file is a valid image of a hard disk, the (hd1) will be accessible by the OS with "standard methods".
Yes.SO. Do you guys know if it's possible to create a blank formatted (or not) drive out of the box with Grub4dos?
By saying map this area of memory as say, floppy, CHS, FAT.
http://homepage.ntlw...no-answers.html
(meaning that we do know if it's possible or not, though "floppy, CHS, FAT" represents a meaningless list of different things "media type, addressing media, undefined filesystem between FAT12, FAT16, FAT32 and exFAT)
It looks more something completely UNunderstandable, at least to me, something like a random generator of geek text may produce, there is NOT a single line that makes sense together with the previous or the following oneBut the main idea being.
For the test:
1 container drive image. (hd-like)
1 Dos boot floppy
1 bootsector and FAT(.bin, .file, .whatever)
After that the files of a second floppy (whose bootsector is the latter) are on the main drive image. The files are in the same order, an Hex-copy.
The floppy images must be same FS as main drive, to, I assume, avoid overlapping FSs.
The FAT of the main drive would list the files of second floppy, as well as a Bootsector and fat. bin.
The files of the floppy are now accessible from windows.
Grub4dos would have to map the offsets from bootsectorfat.bin to end of last file (on main drive), and map thae length as a drive.
Therefore we have a bs, a FAT, and files. In RAM.
It looks more like a proof of concept. Might be useful.
Please try to expand on the idea, explain what EACH thing is, like "fat .bin", "bootsectorfat.bin", "FAT(.bin, .file, .whatever)".
Are you - by any chance - talking about something like OFS?
http://reboot.pro/2887/
Check the floppy teaser:
http://reboot.pro/2887/page__st__14
Wonko
#23
Posted 08 February 2012 - 01:07 PM
Maybe you should state your objective more clearly?
For instance, you could burn a grub4dos bootable CD which contained on it a .img file which was a hdd disk image, grub4dos could load and map it to memory and then boot to a DOS image which should then be able to access the virtual hdd.
Just what are you trying to achieve? There is usually more than one way to skin a cat!
#24
Posted 08 February 2012 - 01:18 PM
I want to be able to access files on a stick, for whatever reason. I want to be able to view these files from within windows (NT).
But these files would usually be stored in an img. For, now just probably proof of concept, maybe a use in future, I want not to use an image mounting tool from within Windows, but still view the files.
These files will, therefore be referenced in the FAT of the stick.
I still want these files to be 'stored in an image'. I.e, be part of the whole stick (in the stick's FAT), but also be referenced as being part of an image.
Let's say a 2.88 floppy image. I will therefore have a bootsector of an image, and a FAT referencing the files for that image.
The bootsector and FAT of the image will be stored on the BSandFAT.bin file. After that file, on the Usb stick, the files of the 2.88 image, in the same order as they are referenced in both FATs.
Then to tell Grub4dos to map the sectors from the start of BSandFAT.bin for a length of 2.88M. Therefore the mapped area would be the representation of a floppy image.
Je vous remercie, et a bientot .
PS, quote:"geek". Yeah. This thing is going that direction.
Edit: @ Steve, thanks, always for input. I started CD, but I'm 'more used to talking FAT' than CDFS, so I decided to 'go FAT'.
#25
Posted 08 February 2012 - 01:23 PM
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users