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.
Related
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)
I managed to create a .deb file from a source program,tar.gz
how can i create an exe file so that the app can also run on windows?i've searched a lot but didnt manage to find any resources.
If you want to run the program under Windows, you'll need to re-compile it from source using a Windows compiler. How exactly to re-compile it will differ from program to program. Check the program's documentation for details or ask its maintainer. ".deb" files and anything else related to Linux package managers have no meaning in Windows, so you'll need to extract the source from the source .deb or pull it from the appropriate source repository.
Be aware that many Linux programs won't build for Windows with a simple recompile alone. If they use any external libraries, then those libraries need to be available for Windows as well. The Cygwin environment may help here. If there isn't already an official procedure for building that particular program under Windows, then you may have to do the porting work yourself (which is a large enough task that it's well outside the scope of this question).
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'm just sort of curious: If I wanted to embed a filesystem in an executable, I assume I'd just embed an image of the filesystem using objcopy. However, what sort of filesystem should I use? Is there going to be an easy library for directly accessing the filesystem image?
I don't have any use for this, so responses like "don't do it, use actual files instead" are irrelevant.
There exist so-called virtual file system implementations, which were designed with custom storage in mind. To name a few: our Solid File System, CodeBase File System, Single File System by AidAim.
Most of them use files as the container, some (eg. our SolFS) let you have container in custom places and access it via callbacks.
Depending on practical requirements you can use ZIP or even TAR format as well.
If you want to expose the filesystem contained in your executable to the OS so that other applications could read it, then one of our virtual storage solutions (CallbackDisk or Callback File System) will do the job for you on Windows. On Linux and MacOS X there exist other ways to do this, including FUSE and MacFUSE libraries (analogs to our CBFS).
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.