At the install of my favourite Linux distro I chose ext4 as my file system. Can my system now make parts of its space (e.g. /home/myname/myfolder) available via NFS? In other words: can /home/myname/myfolder have more than 1 "file system status" (ext4 AND NFS)? Because I already chose ext4 at the install ... ?
Yes but what you're suggesting is strange...
Generally you use a network filesystem (such as NFS) to make a filesystem available to another (remote) machine rather than looping it back to the same machine (if you want to do that a bind mount will be more efficient). So if you are only mounting the NFS share on another machine why would the original system see the same "region" via two different filesystems?
(also technically this isn't a programming question)
Related
How does the Master Boot Record (MBR) change? I can not figure out if there is an MBR specific to Linux-based operating systems, or does each operating system have a different MBR? How do I compare MBRs of operating systems? And if I write one with C for Ubuntu, will it work for other distributions as well?
If an MBR is always cross-platform, does mean that it will work on both Unix-like systems and Windows for example? And if not, what's the difference between an MBR for Windows and MBR for Unix?
In "idealistic theory", for dual boot scenarios, the MBR contains a "Boot Manager" that does things like determine which partitions are bootable, selects one (possibly by offering the user a menu to choose from), loads the selected partition's first sector (the selected operating system's boot sector) and passes control to it.
In this case, the MBR (and other associated code in the first track of the disk) is owned by a third-party utility that does not belong to any OS; and no OS should ever be allowed to touch/modify the MBR (or any other data that is before the start of the first partition).
However, in practice often people only install one OS, and for convenience OS installers provide their own MBR (so that people don't need to worry about installing a third-party utility); and almost every OS has nasty/egotistical "we only care about ourselves and/or want to be in control of any other OS you install" tendencies. This led to operating systems ignoring common sense and trashing each other and/or providing their own "anti-competitive" alternatives for dual-boot scenarios (GRUB and "boot.ini" on Windows).
This nasty nonsense became significantly worse (for users) when manufacturers/firmware started caring about security. The plan was for all code used during boot (including firmware, MBR and the operating system's boot loader) to be "measured" (checksummed using fancy cryptography built into a TPM chip) so that an OS (and other software - e.g., "remote attestation") can detect if malware had tampered with any of the code that an operating system depended on (because that "fancy checksum" would be different).
This means that if you install a second OS (corrupting/modifying the MBR of an existing OS), you change that "fancy checksum" and break the original operating system's identity, so after you fix the damage and get the original OS to boot again various other things (that depended on the "fancy checksum") remain broken.
Fortunately, UEFI mostly fixed this by taking on the role of "boot manager" (and deprecating the MBR completely), where (if multiple operating systems are installed) the firmware uses "UEFI variables" to determine which one gets booted, and each operating system can have its own different boot loaders in the UEFI system partition without conflict.
Sadly, the nasty/egotistical "we only care about ourselves and want to be in control" tendencies remain and operating systems are trying to find alternative ways to ruin everything (SecureBoot key management, using GRUB as a shim so that different operating systems can fight for control of GRUB's configuration, etc.).
How does the Master Boot Record (MBR) change?
The MBR doesn't change unless you install an OS. When you do install an OS, the MBR may or may not change depending on the OS installer and (in some cases) what you tell the OS installer to do.
I can not figure out if there is an MBR specific to Linux-based operating systems, or does each operating system have a different MBR?
Linux (the kernel) defines a "Linux boot protocol" which allows anyone to write a compatible boot loader. For booting from BIOS; there were 3 common boot loaders (LILO, GRUB and SYSLINUX); but most Linux-based operating systems gravitated towards GRUB, and most OS installers for Linux-based operating systems tended to install GRUB in the MBR as "boot manager plus boot loader".
I want to know if an MBR is always cross-platform, means that it will work on both Unix-like systems and Windows for example. And If not, I want to know what's the difference between an MBR for Windows and MBR for Unix.
Sadly, no - the MBR should be "OS neutral/cross-platform" (and can be in some cases - e.g., if the user doesn't mind installing LILO or GRUB in its own partition and if the OS installer supports that), but mostly isn't. If you want to write your own MBR then you'll probably need to deal with a specific operating system's failure to cooperate with other operating systems.
This is just for self-study purpose.
In Windows, Linux or Mac, we can mount many kinds of file system (including SAMBA, Google drive file system, etc) and access them as if there were ordinary files and folders in the hard disk. How to create such file system? I am referring to the file system itself, not to the server where the files are stored.
I prefer if the tutorial is for Mac or Linux (I would guess that the technique will be OS dependent)
This is not as trivial as you might think.
I had to do this some time ago. What I did was to integrate a TCP/IP-based file server into my program and used the network file system functionality of the OS.
Today the "FUSE" project is available for Linux (and as far as I understand correctly) for MacOS X (the last one seems to be named "MacFUSE").
The "FUSE" project provides you a special API which allows you to create a mountable file system...
You install "FUSE" and you can write programs that provide file systems to the OS.
I am wondering if it's possible to write an application that will access a foreign filesystem, but without needing support for that filesystem from the operating system. For example, I'd like to write an app in C that runs on Mac OS X that can browse / copy files from an ext2/ext3 formatted disk. Of course, you'd have to do all the transfers through the application (not through the system using cp or the Finder), but that would be OK for my purpose. Is this possible?
There are user space libraries that allow you to access file systems.
The Linux-NTFS library (libntfs) allows you to access NTFS file systems and there are user space programs like ntfsfix to do things to the file system.
E2fsprogs does the same for ext2, ext3 and ext4 filesystems.
As Basile mentioned, Mtools is another one that provides access to FAT partitions.
There was even a program that does exactly what you're looking for on Windows. It's called ext2explore and allows you to access ext2 partitions from Windows.
It is possible. For example the GNU mtools utility are doing that (assuming a way to access the raw device or partition) for MS-DOS FAT file systems.
However, file systems inside the kernel are usually very well tested and optimized.
Yes and No. For a regular user Application is usually not possible because access to block devices is restricted to root only. Every block device should give read/write to the needed block device for that effect. This would need at best a server/client approach where a service is started on the machine and configured to give the permissions on a per block device manner.
The somewhat easier alternative would be you to use the MacFUSE implementation.
Look here:
http://code.google.com/p/macfuse/
http://groups.google.com/group/macfuse?pli=1
The MacFuse project seems no longer mantained, but can give you a starting point for your project.
The dirty and quick approach is the following as root chmod 666 /dev/diskN
You can hijack syscalls and library calls from your application and then redirect reads/writes to anything like a KV store or a distributed DB layer (using the regular calls for the "virtual devices" that you do not support).
Then, the possibilities are boundless because you don't have to reach the physical/virtual devices when someone asks for them (resolving privilege issues).
I have a few dd images and I wanted to know the best way of extracting files out of these using C. The images are of mixed file systems (fat32, ntfs, ext2/3) and the host machine doing the extraction would be an Ubuntu box, so you can assume kernel headers and GNU C library, etc.
Natively would be best, but external libraries that do the job would also be fine. A link to an example would be perfect.
This is a significant effort. You'd have to essentially reimplement filesystem drivers for NTFS, FAT, and EXT2. I've done this for FAT and NTFS, but it took more than two years, though much of that was reverse engineering NTFS.
Consider using the file mount option of the mount command so you can use the Ubuntu filesystem drivers and not reinvent the significantly large wheel. Then you can peruse the mounted filesystems.
Why programatically with C?
sudo mount -o loop,offset=[offset] -t auto [where] [what]
Where
offset is the offset in bytes from the beginning of the disk, in bytes
where is where on the current filesystem to mount the image
what is the disk image you're mounting
Look at The Sleuth Kit, which should work with all of the file system types you listed:
The original part of Sleuth Kit is a C library and collection of command line file and volume system forensic analysis tools. The file system tools allow you to examine file systems of a suspect computer in a non-intrusive fashion. Because the tools do not rely on the operating system to process the file systems, deleted and hidden content is shown. It runs on Windows and Unix platforms.
The Sleuth Kit's existing toolset is a great place to start if you're looking for sample code to work from.
Check out:
ext2fuse or fuse-ext2 projects, they contain some ext2/ext3 implementations on user space using FUSE.
ntfs-3g, an NTFS implementation also using FUSE.
FUSE itself, as there are lots of filesystem implementations on top of it.
I am new to android kernel and Mobile Operating Systems and I have a few questions regarding android kernel.
1) Does Android OS has Kernel Mode and a User mode like Normal desktop OSs ? Also does it support things like Virtual Memory ? Also I heard about Dalvik VMM. Is a copy of dalvik VMM created for each and every process ?
2) Another Question is I heard android creates a separate file system for each and every process(every application). Is this true ? If so How OS maintains these file systems and where are they mounted. Does it have a hierarchy like Unix based systems ?
3) Another Question is regarding IPC in android. What are binders in android ? How does it differ from normal IPC mechanisms like pipes, msg queues etc.
4) Another Question not related to android but How does the driver address Flash based disks like Solid state drives etc. For ex: normal HDD block can be identified by cylinder, sector and a track.
1. The "Android kernel" is the Linux kernel.
1a. No, you didn't hear about the "Dalvik VMM", you heard about the "Dalvik VM", which is simply a new kind of Java VM. It runs Java apps. No magic. No, there isn't somehow a Dalvik VM associated with "every process", but yes, each application runs in an independent process.
2. No. There's a directory structure, not distinct filesystems.
3. Why Binder?
4. Android uses the usual Linux MTD and MTD-Block devices. And the world is LBA, whether for flash or hard drives. CHS is only for those time-travelling thirty years to the past.
Does the Android kernel have a kernel space and user space?
The kernel used on Android powered devices is a 2.6 kernel providing the core system services like memory management, process management, network stack, and driver model.
So yes it does have a kernel and user space. You have the regular /proc file system for kernel/user space communication for example.
It is true that every application runs in its own process with its own instance of DVM.
You can read more about it on the What is Android? page.
How does the application file structure look like on Android?
Yes every applications has its own directory structure for application data like databases, shared preferences and other application specific files which looks like this.
/data/data/packagename
Other than that the actual .apk files are located in
/data/app
I'm not quite sure about your question if it is a UNIX based hierarchy system. I guess you want to know if applications will be placed in /usr/bin/ and so on. Then no. Except you write some binaries yourself and build your custom image then you should definitely place your system binaries in the default FSH places.
On question three. I'm not quite sure what you are referring to. If you mean the UNIX IPC then well it's a 2.6 kernel with all it's core functionalities like states above. If you are referring to Remote procedure calls of the APIs then you might take a look at Remote procedure calls.
Question four is beyond my knowledge or I didn't get your question.
Generally I'd recommend you some very interesting reads.
What is Android? like stated above.
Android Application Fundamentals
Android Sources page
Hope it helped somehow.
1) If you want permissions for various operations you need to enable them in the manifest.
2) Yes. Each application has its own file-system, but the files are accessed by file name only (no path). If you want to use external memory such as an SD card, you need to enable permission in the manifest, and use a fully qualified path/file-name.
3) I am not familiar with android binders (though I see them while debugging), but passing messages between tasks is very straightforward.
4) Flash based memory blocks are identified by address. Flash is not RAM, but it is random access.