I want to add a backup functionality to my app in the sense that the app will allow users to create a self-contained environment (data + executable + autorun.inf file) on an external device (CD, CD-ROM or USB key) so that users can retrieve (in read only mode) their stored environment at a given point in time.
I've read here about making an auto-bootable USB (which I suspect will be the same for a CD or DVD).
edit I meant "auto-executing", not "auto-bootable"!
I know about IMAPI or other approaches that are now several years old. Is there any alternative/standard approach to create media this way? I'd like a generic way to create either CD/DVD or USB devices (non-bootable).
You need to make sure to not confuse Booting and Windows Autorun.
auto-bootable USB
refers to an external USB drive from which you can boot your computer.
I doubt that's what you are looking for, given the linked Stackexchange question. The information you already found is actually what you are looking for, and the advice given there seems pretty accurate.
What you need to do is:
Create the media with your data. In case of USB sticks this is as easy as copying the data to the stick. Optical media (CD/DVD) need to be burned, and that can only be done using the Windows API, which has already be discussed here.
If you want to use the Windows autorun feature (which I would ignore*), you'll need to create a file called Autorun.ini in the root directory of your media. You already have found the required content of that file here.
* Why I would skip the autorun feature.
First of all, there's no real alternative to the Windows autorun feature.
It was controversial, at best, in earlier versions of Windows. Since USB sticks went mainstream, autorun became nothing more than an automatic virus installation feature. Soon after everyone started disabling it. Because of this recent versions of Windows seem to have dropped it or disable it by default.
An exception to this would be the Icon=diskicon.ico option, which allows you to change the icon of the drive. This might be still working, even if autorun is disabled.
Related
I work for an IT company where we all carry around flash drives that have our most used programs on them.In my spare time I am hoping to create a "main menu" item that is kind of a fun and convenient way to access these files. I am working on creating this using Visual Studio 2013 and using visual C# windows forms. I have come across a snag however that I can't seem to find a workaround for. I am by no means fluent in C#, but I need to have a button on the windows form open a file without specifying what drive it comes from. I understand that I have to specify a path, but as these will be stored on the flash drives of myself and my coworkers I cannot foresee that the path will always begin with E:. Depending on what USB slot the drive is plugged into it could be N: or F: or the like. I have provided an example below:
Using what I currently know I am opening files using this line of code:
System.Diagnostics.Process.Start("C:/Users/Myname/Desktop/Asmodeus/Anti-Virus/Anti-Virus Installers/avast_free_antivirus_setup.exe");
Is there any way possible I can have the file open simply from
System.Diagnostics.Process.Start("Asmodeus/Anti-Virus/Anti-Virus Installers/avast_free_antivirus_setup.exe");
or something of that nature?
Thanks in advance.
There must have been some mis-communication when I asked my question previously. what I am looking to do is open an executable file via a button click on the windows form using a relative path. I am not able to specify the absolute path because the application will be run from a flash drive and therefore will change depending on what USB slot it is currently inserted into.
What I am hoping to accomplish is insert a line of code that will allow me to open an executable file that is located in the \bin\debug folder along with the application itself. I have a picture for clarification but apparently do not have enough reputation to post it. Thank you and sorry for the earlier confusion.
Usually you can just use Environment.GetFolderPath (MSDN) to give you what you need. It doesn't do absolutely everything, but if you need Desktop and the like, that is plenty.
Depending on the target version of .Net, the SpecialFolders exposed are not all there. It may turn out that you need more than they provide, but in your case it doesn't sound like it.
If there is more you need that is not covered in the default, check out this project. I'm sure there are others like it, but it does a little more than the default BCL version, using the API directly. It is at least something to read and learn (and translate from vb.. use an online translator, very quick). I haven't looked at it, but it seems like you are learning this c#/.net thingy, so it might be helpful
This article is about accessing Windows special folders.
These folders include your “Favorites”, “Cookies”, system libraries and the like.
Here is code, including a large number of constant definitions, plus documentation,
allowing access to and creation of these folders.
I want to build an app that needs to monitor the opening of the files but I don't find any way to can do it.
With FileSystemWatcher there is no option to can monitor the opening of the files. Just the created, removed and modified ones.
So I wonder if there is any functionality implemented in the advanced searches that could give me the infomration of the files opened after a concrete date. (At least in Mac it's possible but I am not sure if Windows has implemented this)
Other solution would be to develop a File System Filter Driver, but I find this way too hard
I cant give you a direct answer (because I dont know) but since Microsoft publish the FileMon tool which does exactly what you are after, it seems that Windows does have a way of notifying file open, close and access. This is discussed here Getting a notification when a local file is accessed in windows but this only covers the change of files, not opening and closing. There is a way of getting all the files opened by a process discussed here Delphi - get what files are opened by an application which is possibly what FileMon is using, but there are caveats (i.e. its an internal OS API).
Hope this helps, sorry cannot give a direct answer.
I was thinking of messing around with my own file system code, as a learning exercise. To start with this could be a RAM drive, or just mounted within a file on another drive. Questions:
What windows APIs would I need to program to implement my own drive letter (eg an M: with my system)
Where is the documentation for these APIs?
Can you implement them using C#?
NB:
I know there are other Ram drive implementations out there - I don't need a list of them.
I've tried googling, but found it very hard to find the right search terms.
I'm not fussy for now about which version of windows, any version is fine as I'm developing using Windows 7, but I hope that version for earlier Windows will still work
Take a look at the IFS (Installable Filesystem) Kit.
You're talking about writing a filesystem driver. The basic model is that your code gets loaded into the NT kernel and processes IRPs.
No, you can't do it in C#.
You need to look at the Windows DDK - now called "WDK" apparently. The WDK includes the Installable File Systems (IFS) kit. See here:
Installable File Systems (IFS) kit
Device drivers on Windows are written in C/C++. As far as I know there is no way to implement a file system driver in .NET. There is no CLR in kernel space.
EDIT: asveikau beat me to it...
From this answer to a similar question: how to map a software as a Drive?
Have a look at Dokan. It looks like a nice scriptable wrapper to low-level filesystem drivers. Like FUSE on Linux.
The docs page mention that you can use it to write filesystem code in C#, VB, C++ and even Ruby! Since it exposes itself as a .Net library I'm guessing you can do it in any language running on the CLR as well such as IronPython or F#.
Depending on what you need (implement a file system or just a virtual disk with existing file system) you can use one of our virtual storage products: Callback File System and CallbackDisk respectively.
The difference is that CallbackDisk emulates a disk device (so you can mount, for example, ISO image there), and Callback File System lets you build your own file system (eg. distributed, or just remotely stored)
.NET APIs are available in both products.
I want to write a program that will encrypt an entire folder and it's sub-folders, I have no problem doing this but I would like to make the entire encryption process rather transparent by letting a user double click it and have it open as if it weren't encrypted, say if it were a picture or a word document and it'd open in it's respective application.
How can a running program of mine become notified about the opening of a target file, stop the file from opening, do what it needs to do (decrypt), followed by running the resulting decrypted file.
How can I watch a file and do this in C#? Can I watch for other interactions like the user copying a watched file (since it won't be in a watched folder, it should be decrypted i.e. it's dragged to a USB device), or for deleting a watched file (say if I want to shred a file before deletion)?
P.S. The FileSystemWatcher doesn't quite meet my needs. EDIT: What I mean is that FileSystemWatcher will tell me when a file is being opened, deleted and all those events, but it won't let me step in real quick, decrypt the file, and hand it back to the process that normally opens that file.
You can rename files, add them your own extension, like thepicture.jpg.encrypted. Set your program as a default program for this extension and handle opening them
It's impossible in C#. the bare minimum would need you to use user-mode hooks on NtCreateFile, NtOpenFile, etc. You can't achieve that in C#. That wouldn't even work properly due to kernel-mode code which may try to access your files. The proper way of doing this would be to write a I/O minifilter (in C of course).
EDIT: If you're really desperate, try EasyHook - it allows you to hook functions from C#. I haven't tried it though, and it does seem risky hooking vital functions like NtCreateFile. Plus you need a fair bit of Native API knowledge.
Are you using Windows? If so, why not use the built-in BitLocker?
See this link:
BitLocker drive encryption
If you are thinking about a competitive application to BitLocker, add a comment, as I can point you in that direction as well.
Instead of trying to reinvent the wheel, use NTFS file encryption. You can encrypt single files or entire folders or drives. Plus it's completely transparent to the user and does exactly what you asks (e.g. automatically decrypt when copying to a UBS drive, etc). Just use System.IO.File.Encrypt(string) - there couldn't be anything easier.
You can't do this from usermode.
Unfortunately the only way to do this is to write a minifilter driver. Minifilter drivers allow you to intercept IO requests to files, you can then encrypt/decrypt the files you care about on the fly.
It sounds simple, but encryption minifilter drivers are very, very, difficult to get right. You will have to end up shadowing file objects which is a real challenge. Check with www.osr.com, they have a ton of information on doing exactly what you want to do.
If you choose to go this route I would recommend getting a copy of VMWare Workstation and download VirtualKD. It will let you debug at near fire-wire speeds into a VM. I would start with x64 Win7 and get remote shares working first.
One of my favorite things about owning a USB flash storage device is hauling around a bunch of useful tools with me. I'd like to write some tools, and make them work well in this kind of environment. I know C# best, and I'm productive in it, so I could get a windows forms application up in no time that way.
But what considerations should I account for in making a portable app? A few I can think of, but don't know answers to:
1) Language portability - Ok, I know that any machine I use it on will require a .NET runtime be installed. But as I only use a few windows machines regularly, this shouldn't be a problem. I could use another language to code it, but then I lose out on productivity especially in regards to an easy forms designer. Are there any other problems with running a .NET app from a flash drive?
2) Read/Write Cycles - In C#, how do I make sure that my application isn't writing unnecessarily to the drive? Do I always have control of writes, or are there any "hidden writes" that I need to account for?
3) Open question: are there any other issues relating to portable applications I should be aware of, or perhaps suggestions to other languages with good IDEs that would get me a similar level of productivity but better portability?
1) There shouldn't be any problems
running a .NET app from a flash
drive.
2) You should have control of
most writes. Be sure you write to
temp or some other location on the
hard drive, and not on the flash
drive. But write-cycles shouldn't be
a problem - even with moderate to heavy
usage most flashdrives have a life
time of years.
3) Just treat it
like's it any app that has xcopy
style deployment and try to account
for your app gracefully failing if
some dependency is not on the box.
If you want to use com objects, use reg-free com and include the com objects with your program.
You should always have control of your writes. Applications should be loaded into RAM at startup, and then memory past that is allocated in RAM, so nothing is written to the flash drive.
The most important thing for a portable application is that basically no installation is necessary for your application. You do not want to be dependant on registry values especially, since your application will not be 'installed' on other computers.
One of the issues with portable applications you may consider is data persistence. Generally, you write to a user's Application Data folder to save data. If this is the case, any data saved will only apply to the user on that computer. If you want some local application data, you may wish to create a Seralized XML file for your settings and store it locally within your application's directory. This file writing would then likely be the only write actions you'd need to worry about.
For your .NET portability issue, you could also write a small entry program in C++, which checks if the computer has .NET installed. .NET has registry values you can check to see the versions installed, so if .NET is installed, run your application, else display a message stating that .NET needs to be installed first.
Edit: I'd like to add that I do application development for Ultrasound machines using XAML in C# 3.0. The application I write works perfectly from a USB Flash Drive, while all user settings are stored on a local AppData basis, so nothing is written to the USB. While the application can be installed through an .exe installer, the installer does not write any registry values the application depends on.
I don't really have answers for #1 or #3. But for #2, the .NET CLR shouldn't be writing to an app's "installation" folder (i.e. the flash drive) unless your code specifically tells it to or is using and modifying file-based settings (ini, xml, etc) that live with the app.
Number 1 is really the kicker if you're not just writing things for personal use. Obviously hosting a portable copy of the full CLR on the thumb drive is impossible. But there are tools that can scan your assembly for its dependencies and package them up into a standalone .exe so that the CLR doesn't necessarily need to be installed on the target system.
I don't actually have any experience with this so it might be best to take what I say with a pinch of salt. But here is my take on it:
You don't need to do anything special.
It is not really a consideration of an application developer as to how and when writes are made to a drive, that is something that is far better controlled by the OS. I know that Windows caches writes to USB drives so I would trust it do handle that.
The only thing you need to consider is that your application will not be installed. So you need to make sure that you design it to run entirely self contained within the directory it is deployed to. You could optionally also make some writes to the users home directory but this needs to be done through the appropriate environment variables.
I would get writing and see if there is anything special about a flash drive that the OS doesn't handle.