I’m looking for a code snippet that would programmatically format unallocated space on a given drive.
I’m ideally looking for .net code (VB.NET C#) or C++.
Many thanks
The best option seems to be to use WMI. In particular, you'll want to look into the Format method of the Win32_Volume class.
You could instead use the SHFormatDrive function of the Win32 API. This may be the simpler option (especially in C++), though I'm not sure how the functionality compares with the WMI method. Edit: As M. Jahedbozorgan points out, this seems to open the Explorer shell dialog to format the drive.
A third option is to run the command-line format.exe from code (and then read from the stdout stream), but this clearly isn't a very nice solution.
Other suggestions are given in this thread on MSDN forums.
Create a file that fills up the entire drive, then write random data to it, then flush it, then close it.
The first step is probably the hardest to do reliably across multiple configurations (e.g., NTFS compressed volumes or per-user quotas).
Or use "cipher /w" from the command line.
It looks like Windows only provides a method to format an entire volume, not just the unallocated space.
So, if I understand your question right, you could create a partition in the remaining space of the drive, then format that new partition.
You will want to use PInvoke and WMI's Win32_Volume.
Related
I'm currently working with a Chinese SMB server, on which almost all the company files are stored.
As the structure doesn't change, I'd like to be able to put a "label" on files, based on a rules (something that allow me to handle generated files, which includes dates for example).
I need only support for win7 and above, and I'd like my informations to be read from a text file rather than relying on some metadata or client's data.
So I thought of writting a shell extension to do the work. My problem is, that by looking at the documentation, I didn't find something that allow me to change the name. The best solution I've found so far is to go with the infotip handler, but I wondering if anyone has a better way to do this.
In short, it needs:
1) To be compatible with win7 (and above),
2) To be visible at first sight
3) To use a readonly fs
After extensive research, I've found that the best way to do it is to write a Shell Namespace extension.
I'll be able to provide a virtual directory representing my server's structure, and translate the names the way I want.
This seems a little overkill though, but there's no other way to change the informations displayed as the display name is managed by an IShellFolder which provides it to an IShellView
One excellent source of informations I've found about it, and the most up to date so far, is an article on Michael Edenfiled's blog
Let's say I have a file: test.txt and I save it on my harddisk.
Is there a way to determine on what (physical) spot the file is saved on the hard disk?
For example on vector 12 on track 10 of the hard disk.
I don't know if I got the terminology right of the above, but I hope you get what I mean.
I want to write of program wheer the user can point to a file and the program will find out where the file is on the HDD. Something like the old defrag (it's Windows ;) ) where it shows what parts of the disk is in use.
What is this called and can it be achieved? (I'm not looking for code (although exmaples are ok ofc), but rather whether it is possible)
P.S. The client will be Windows 7 (so think NTFS if it matters).
I'm pretty sure that doing that sort of low-level disk i/o in managed code is going to be...difficult, at best. Here's somebody that's done something like it:
http://codebrainz.ca/index.php/2010/05/23/low-level-disk-io-in-managed-net/
Anything you write to do something like this has to be hardware-dependent: unless you know what hardware you're talking to, you've got no idea how it physically stores data (e.g., a USB memory stick has neither platters, tracks nor sectors, nor does it spin. Yet, for all intents and purposes, it appears to be a disk).
Normally, you'd write some sort of device driver to accomplish this. This link
http://en.wikibooks.org/wiki/Windows_Programming/Device_Driver_Introduction
might help.
In Jeffrey Wall's WebLog you will find Defrag API C# wrappers. His GetFileMap method sems to come close to what you need.
It is possible from C++, so with a little interoping, you should be fine.
Look up FSCTL_GET_RETRIEVAL_POINTERS in the MSDN to get you started.
I would like to copy files into an encrypted truecrypt partition using programming(c#) without mounting the partition.
Is it possible?
If so, may you give me an example code to do this!
Thank you!
possible? - yes.
easy enough to get an implementation for free? - probably not.
the TC source code is available, so the needed crypto stuff is there. you will probably want to port that to c# or build a dll that can be called by your c# prog.
additionally, since you are not mounting the container/partition, you will need a reader/writer for whatever filesystem is inside. FAT should be rather easy to do, but when it comes to NTFS, you maybe want to have a look at an open source NTFS driver ...
Is this even possible?
I realize that asking them to enter data when the program runs and saving it in the executable file itself is out. (Or is it?)
Right now I'm considering trying to build the program server-side with php and have it incorporate a separate text file which would contain the information. This seems marginally feasible, though I would have quite a bit of learning to accomplish it.
I was hoping for some other ideas of how I might accomplish this.
I am not interested in separate configuration or text files or putting data in windows registry. I am only looking for solutions where it can be quite-solidly a part of the executable.
Does anybody have any experience with this?
Thank you.
Its perfectly possible, that's how self-extracting zip files work.
Basically, you can add as much stuff to the end of the executable file as you want. Your program can then open its own file up on disk and read it back.
How about using Settings within your app? It depends on what you mean by "storing the user registration" as to how you would best achieve this, though. If you could give some more information about what you actually want to store, that would be useful.
An example would be to save a username, or an authentication token, and use that each time you need to check a "registration". As I say, though, the details of what to store would depend entirely on what you want to do it that data...
You could use it to embed in the unmanaged resources.
Hey guys.. I am writing a Windows application in C# that minifies CSS files and packs JS files as a batch job. One hurdle for the application is, what if the user selects a JavaScript file that has already been packed? It will end up increasing the file size, defeating my purpose entirely!
Is opening the file and looking for the string eval(function(p,a,c,k,e,d) enough? My guess is no, as there are other JS packing methods out there. Help me out!
One might suggest that you compare the size of the pre and post packed JS and return/use the smaller of the two.
UPDATE based on question in comment by GPX on Sep 30 at 1:02
The following is a very simple way to tell. There may be different, or more accurate, ways of determining this, but this should get you going in the right direction:
var unpackedJs = File.ReadAllText(...)
var unpackedSize = jsContent.Length;
var packedJs = ... // Your Packaging routine
File.WriteAllText(pathToFile, unpackedSize < packedJs.Length ? unpackedJs : packedJs)
I would check file size and lines of code (e.g.: average line length). These two information should be enough to know if the code is sufficiently compact.
Try this demo.
I direct you to a post that suggests packing is bad.
http://ejohn.org/blog/library-loading-speed/
Rather use minification. Google Closure compiler can do this via a REST web service. Only use a .min.js extension for minified (not packed).
Gzip will do a better job and will be uncompressed by the browser. Its best to switch on zip compression on the server which will zip a minified file down further.
Of course this raises the question 'How can I tell if my Javascript is already minified!'
When you create/save a minified file, use the standard file name convention of "Filename.min.js". Then when they select the file, you can check for that as a reliable indicator.
I do not think it is wise to go overboard on the dummy-proofing. If a user (who is a developer, at that), is dumb enough to double-pack a file, they should experience problems. I know you should give them the benefit of the doubt, but in this case it does not seem worth the overhead.
If you're using a safe minimization routine, your output should be the same as the input. I would not recommend the routine you mention. MS's Ajax Minifier is a good tool and even provides dll's to use in your project. This would make your concern a non-issue.
I would suggest adding a '.min' prefix to the extension of the packed file, something like 'script.min.js'. Then just check the file name.
Other than that, I would suggest checking how long the lines are, and how many spaces are used. Minified/packed JS typically has almost no spaces (typically in strings) and very long lines.