When I boot up Linux Mint from a Live CD, I am able to save files to the "File System". But where are these files being saved to? Can't be the disc, since it's a CDR. I don't think it's stored in the RAM, because it can only hold so much data and isn't really intended to be used as a "hard drive". The only other option is the hard drive... but it's certainly not saving to any partition on the hard drive I know about, since none of them are mounted. Then where are my files being saved to??
Believe it or not, it's a ramdisk :)
All live distros mount a temporary hard disk in RAM memory. The process is completely user-transparent and is all because of the magic of Linux kernel.
The OS, in fact, first allocates an area of your RAM memory into a virtual device, then mounts it as a regular hard drive in your file system.
Once you reboot, you lose all your data from that ramdrive.
Ramdrive is needed by almost all software running on Live CDs. In fact, almost all programs, in particular desktop managers, are designed in order to write files, even temporary, during their execution.
As an example, there are two ways to run KDE on a Live CD: either modify its code deeply in order to disallow you to change wallpaper etc. (the desktop settings are stored inside ~/.kde) or redeploy it onto a writable file system such as a ramdrive in order to avoid write fails on read-only file systems.
Obviously, you can mount your real HDD or any USB drive into your virtual file system and make all writes to them permanent, but by default no live distro mounts your drives into the root file system, instead they usually mount into specific subdirectories like /mnt, /media, /windows
Hope to have been of help.
It does indeed emulate a disk using RAM; from Wikipedia:
It is able to run without permanent
installation by placing the files that
typically would be stored on a hard
drive into RAM, typically in a RAM
disk, though this does cut down on the
RAM available to applications.
RAM. In Linux, and indeed most unix systems, any kind of device is seen as a file system.
For example, to get memory info on linux you use cat /proc/meminfo, where cat is used to read files. Then, there's all sorts of strange stuff like /dev/random (to read random crap) and /dev/null (to throw away crap). ;-)
To make it persistent - use a USB device - properly formatted and with a special name. See here:
https://help.ubuntu.com/community/LiveCD/Persistence
Related
I work on-the-side doing computer repair. Standard operating procedure is to pop out the HDD/SSD, mount it to a backup machine, and pull the client's data (i.e., in case the drive fails/something goes horribly wrong, their data is protected). More and more often, my office is seeing SSDs soldered directly to the motherboard, making this technique impossible.
I was wondering if any of you knew of a some method that would allow direct disk access without drive removal. An analogue would be mounting a phone in Mass Storage Device mode, I suppose. This may be possible already by doing something with a Linux LiveUSB, but I'm not sure how. Booting from a LiveUSB and transferring files over the network is unacceptably slow given the volume of computers we see and amount of data involved.
On Apple computers, this is simple--plug in a Thunderbolt/Firewire connector and use Target Disk Mode to pull directly from the drive.
tl;dr: making a backup of a Windows computer without opening them: how do?
Boot a live Linux from a large USB3 HDD, and use the same disk to copy the client's data to with about USB3 speed.
I am creating an operating system, and am able to create a simple multitasking kernel (though the code has been lost) and an IDE/ATA PIO driver without BIOS interrupts. I wish to create a boot loader that puts the system into Protected Mode, disables paging, creates a flat memory model, and then does a long jump to the 0x0 offset of a file named OS.SYS in the root directory of a FAT32 formatted hard drive. I know how do do everything except for one thing: change the boot sector of the disk. I know how to format a hard drive as FAT32 to get the correct BPB and such at the beginning of the file, but I do not know how to copy over the code so that the BPB is not corrupted. Even in Linux when DD was available, I was unable to overcome this hurdle - I always used a custom file system. I am now seeing the disadvantages to this, though, such as not being able to use simple tools like file managers to move files around for testing.
Basically, to sum it up, I'm asking how to change the boot sector code on an already working FAT32 file system without messing up the BPB.
Note: I am using Windows 10 and NASM, and intend to use virtual hard disks with QEMU or Virtualbox.
I have found a program that can make you save space by hardlinking files that are actually the same, thus leaving only one copy of the file on the file system with more than one hardlink pointing to it. The program is called hardlink.
This is very nice as I have at last found a way to save space on my backup disk for old backups I have made before I knew about rsync and incremental backups.
After such a lengthy introduction, any reader would expect a question, so here it is:
Would it be safe to use hardlinks to save space on a ntfs partition? The hardlinks would of course be created from Linux, using the hardlink program mentioned above. More precisely, will Windows (any version) be able to then use the files that would have been replaced by hardlinks?
Many thanks
There are hardlinks on Windows. They are created by the CreateHardLink system call in kernel32.dll. As to whether your hardlink program would work over remote shares, I wouldn't know, but a native one or one from cygwin would.
Now the real question is whether or not Windows programs handle them. Even Windows Explorer fails to calculate disk space used for hardlinks correctly.
I did a small test. Creating a hardlink (using 'ln TargetName LinkName') yields the same file at creation time, but after that the file and the hardlink content change independently. I would therefore discourage any use of unix based hard links on an NTFS partition. Use either an Ext4 partition (linux only) or software adapted for windows-like links on NTFS partitioning (windows software or perhaps some linux software if explicitly mentioned).
I guess that the program hardlink will either fail because hard links doesn’t exists on Windows or create Windows shortcuts.
This isn't necessarily a programming question, but I've hit a performance bottleneck with disk IO and I'd like to try writing and reading from RAM instead of the hard drive. I want to create my file in RAM and then run my application against it.
There are lots of tools for creating RAM drives. None of them seem to work for windows 2008 R2. Does anyone know if this is possible and if so how. Does anyone know of a tool that works?
Use Memory-Mapped Files to map the file into RAM (including memory backed to pagefile, if it's large. so be careful).
File mapping is the association of a
file's contents with a portion of the
virtual address space of a process.
The system creates a file mapping
object (also known as a section
object) to maintain this association.
A file view is the portion of virtual
address space that a process uses to
access the file's contents. File
mapping allows the process to use both
random input and output (I/O) and
sequential I/O. It also allows the
process to work efficiently with a
large data file, such as a database,
without having to map the whole file
into memory.
whatever ram disk you choose to purchase or write, remember check if the ram disk driver responds the SetDispositionInformationFile call.
I ended up finding and using Vsuit Ramdisk (Server Edition). It works great but its not free.
I want to move my program to USB memory stick. It will run only on memory stick and would not be copied (written on C# and has nearly 3GB of database).
Where can I find a good source for that and/or how can I do that?
What you described can't reasonably be done. If a user can run the program, they can run it. It doesn't matter whether they loaded it from your USB stick or not. You can write it such that it assumes it's being run from the USB stick (with relative paths, per #Kos's comment) but that will in no way prevent people from copying it to their hard drives and running it. Since you don't know where a USB stick will be mounted ahead of time, you can't even use absolute paths.
Allow me to disagree with nmichaels, it is possible to check in C# if your running from removable storage or hard drive.
Check this thread: How to detect if any specific drive is a hard drive?
However, it would be too easy to reverse the thing and allow it to run on hard drives.
As an additional protection, you can read the USB drive serial and if it doesn't match, kill the program.
OR... you if want to be hardcore, use a specific USB drive model, and read the VID/PID, or the chip itself (check mass production tool).
In the end, if the program worths it, someone would still reverse it and break the protection scheme :)