I need to merge content of multiple NTFS folders into one based on some rules.
These rules will ensure that there is no conflicting names. The goal is to do all that programatically (c# and/or c++).
The simplest solution I had is to create NTFS Link (or Junction) into the target folder pointing to each file in the source folder.
This would work so far, but the problem I have is that additional files will not occur and removed files will not disappear.
Well, of course I can run a background process (service) listening at the file system's source folders and performing appropriate modifications of NTFS Links on thy fly, but is this the way to go?
The first question is:
1. What is the most elegant way of doing that?
2. I have seen multiple programs which for instance can mount content of a ZIP or ISO file to some NTFS folder. How do they work?
Here is one project that enables you to create a usermode file system in Window: Dokan:
When you want to create a new file system on Windows, for example to
improve FAT or NTFS, you need to develop a file system driver.
Developing a device driver that works in kernel mode on windows is
extremely difficult. By using Dokan library, you can create your own
file systems very easily without writing device driver.
Mapping something to an existing folder is possible in two ways:
Filesystem filter driver filters FS requests to the existing folder and shows modified content of the folder.
Filesystem driver creates a virtual filesystem and mounts it as a junction point on NTFS drive.
Both methods require a corresponding kernel-mode driver.
Applications that expose a ZIP (or other similar file) use one of the above methods. ISO files, being images of the disk, can be exposed directly as virtual disks and also mounted to NTFS folder. In the latter case kernel-mode disk driver is needed.
Your particular task can be accomplished using our Callback File System (CBFS) product. CBFS offers a pre-created kernel-mode driver and lets you write your filesystem-related code in user mode. CBFS includes Mapper sample that does almost what you are looking for - it shows contents of an existing folder as a new virtual filesystem, which you can mount to NTFS folder (CBFS supports this). Non-commercial licenses are available for public non-commercial projects. APIs are offered for .NET, C++, Java and Delphi.
Related
I have developed a CD Burning Application with C++ using Windows IMAPI.
However, now I want my disc to be able to function like Live File System (Like USB).
Basically, I want to have the capabilities that Windows Explorer provide in below screen shot:
May I know if there is any Windows API I can use to be able to achieve this?
The "Like a USB flash drive" file system is also called Live File System.
Live File System is the term Microsoft uses to describe the packet writing method of creating discs in Windows Vista and later, which allows files to be added incrementally to the media. These discs use the UDF file system.
Older Windows versions do not have support for reading the latest UDF versions. If users create DVD/CDs in Windows Vista using UDF 2.50, these may not be readable on other systems, including Windows XP and older (pre-Mac OS 10.5) Apple systems unless a third-party UDF reader driver is installed. To ensure compatibility of disks created on Windows Vista, UDF 2.01 or lower should be selected.
Live file system is based on InCD technology developed by Nero AG for Microsoft Windows.
InCD is a packet writing software developed by Nero AG for Microsoft Windows.
InCD allows optical discs to be used in a similar manner to a floppy disk. The user can drag and drop files to and from the disk using Windows Explorer, or open and save files on the disk directly from application programs.[2]
InCD formats media, and writes to Universal Disk Format. Systems which do not support UDF (such as Windows 98) will only present a HTML page (stored on the disk, outside the UDF part), explaining the problem and linking to a free UDF reader software.
As stated above Live file system uses FsiFileSystemUDF internally.
Following are the file systems supported by IMAPI:
FsiFileSystemNone The disc does not contain a recognized file system.
FsiFileSystemISO9660 Standard CD file system.
FsiFileSystemJoliet Joliet file system.
FsiFileSystemUDF UDF file system.
FsiFileSystemUnknown The disc appears to have a file system, but the layout does not match any of the recognized types.
Live file system works in following way:
However, if you’re using a non-rewritable disc, you can still only write to every area of the disc once. For example, if you burn a 50 MB file to the disc, then delete it later and burn another 50 MB file to the disc, the total space used on the disc is still 100 MB. The original 50 MB you burned to the disc is still present, although it’s been marked as deleted and won’t be shown when you use the disc.
If you’re using a rewritable disc with the Live File System, space used by deleted files will be erased immediately and the space will be reclaimed. This is a big advantage for rewritable discs – you can write to them and delete files as if you were writing to a USB flash drive, without having to perform a clunky full-disc erase operation every time you want to erase some files.
The same happens with FsiFileSystemUDF supported by IMAPI. FsiFileSystemUDF is most advanced and supported by most of the devices. So, you may consider using FsiFileSystemUDF file system.
USB Like behavior is achieved by allowing to writing same disk more than once. This can be achieved by not closing/finalizing the disk. This way, when each time you attempt to re-write new (or old) data to disk, old data is erased - space is lost on non-rewritable disk - data is written freshly. You may read more about finalizing the disk here.
Please note, I am not suggesting that FsiFileSystemUDF is exactly the same as Live File System. As mentioned above, Live file system is not developed by Microsoft and not supported by IMAPI.
I know how to register and mount a file system using a kernel module. Now I want to do the same from a normal c/c++ program. Just overriding file and inode operations for a single folder would be even better. I know there are libraries like FUSE but i think all they do is add a kernel which somehow communicates with the normal program. Is there any way to do this?
Yes, the code for the ext2/3/4 file system is also available as a library.
Not that it's really necessary. If you're just toying around, ext2 is simple enough to implement yourself. On Linux you can just unmount a filesystem and then access the partition as if it was one big file. (Got to be root for this, of course). I'd recommend getting a USB stick for this, though.
The idea of "overriding file and inode operations for one folder" suggests that you want to share access with the OS, though. That does not work. There is one party in control, and that's either your program or the OS, not both.
You can get somewhat close by replacing that one folder with a symlink to your own filesystem, though, but that would have to be a FUSE filesystem. (Assuming you want to stick to user mode - FUSE is how the kernel talks to user mode file systems)
I want to enumerate all the files on a disk. I am using WinAPI FindFirst/FindNext for enumeration. But this method is taking a alot of time. I read somewhere that we can enumerate very fast by reading the ntfs master file table which contains all the information regarding every file on the disk. Is there any API or some method in c++ to read the ntfs master table?
There is no C++ library functionality which would be OS specific, since this would not run on other platforms, or against other file systems.
What you are really looking for is Windows API functions, not std C++ library functions.
Your best source for that kind of information might be the the Linux NTFS file system driver which is actually a Linux user space file system.
We manage an legacy system from the early 80s. It is awkward to access the file system on it, and we're therefore thinking on methods to work with the files from Windows.
We have looked at two methods for doing this:
Create a user space file system (eg with Callback File System).
Looks to me like the best solution, but it is expensive
Create a CIFS/SMB server to share the files on the network and mount using "net use"
I'm not sure if this option even is possible
I have not found any good examples of how I write an SMB server. Maybe there's a reason for that?
My questions are:
Is the method two possible?
Is it possible to mount a CIFS/SMB share locally if there is no network connection?
What are the pros and cons of the two methods?
Edit
The legacy system runs under Windows in a house developed emulator (which works in much the same way as VMware). It is in this emulator we want to expand the functionality to distribute the file system in the legacy system to Windows.
The legacy system is totally unique. Both the operating system and file system is house developed (and very odd).
I want to make an application in qt 4.7.4 where I need to use shared folders in Windows.
I have searched around and found that I can use QDir(hostName), but there is a problem:
I can't control the bandwidth used. I'd like to be able to set the max transfer rate when
accessing a host in the network.
More about the app: I have a folder on my computer whose content I wish to be identical on all the hosts(who's name will be provided from a file) in my network . For example if I add a new file in that folder and run the app, it should start copying the file in the hosts with the max bandwidth used specified by me.
Thank you in advance for your help.
I suppose that bandwidth manages by operating system drivers or services like QoS or firewalls. QDir use only interface provided by operating system to access directory. It works fine with shared dir only because of Windows shared dir behaves the same way as usual dir.
By the way you may try control bandwidth manually by implementing your own file copy procedure. Sorry if my solution too naive or doesn't fit. You may open file (see QFile) in shared directory for read-only and open file on local machine in write-only. Next you start reading portions of data from shared file by timer (see QTimer). So you can specify how often you want to copy portions of data (QTimer parameter) and how many bytes of data you copy per time (QIODevice::read function parameter).