I'm working on a project with WINAPI, where I open and edit files, and sometimes a remove data, so I'm wondering if I can set the end-of-file, so when I close the handle it doesn't save the data past the EOF. Is this possible, if so, how?
I figured it out, found the function SetEndOfFile, thanks, sorry, Brad.
Related
I'm looking for a way to find and kill specific processes in bash, for example, say I have a script that opens a text file, and this is in a loop opening the text file over and over again, so the same text file is overlapping itself, how would I go about closing the previous text file before the next one can open? I've found several ways on here explaining how to kill specific processes by name or PID, but none of them give me what I'm looking for, and I'm unable to get a lot of the answers offered to work, have spent a while trying to figure out this small issue, just wondering if anyone can offer anything. Thanks.
Opening and closing files, as you are doing, is handled by the various programs that you run. Bash does not have separate operations to open and close files explicitly, only ways to read and write them. You can kill a process to ensure that it can't do anything further with a file, but you'll have to be more specific if that is not what you're after.
Alright, so, I'm working on a script to execute some commands in an MMC Snapin, and I'm not very experienced with doing this kind of scripting, but i've made a lot of progress...the problem I am having, is if I create a new object every time the script runs, it will massively delay my overall script while the snapin and everything in it loads(which can take as long as five minutes). If it could load the snapin content once and then just take control of it as needed, and only create a new object IF there's not one open already, I'll save a massive amount of time when I run the script sometimes 100 times in a day.
The problem is, I'm not entirely certain how to achieve this. I thought, after some research, that it would be GetObject, but when I do
Dim objMMC
Set objMMC = GetObject("", "MMC20.Application")
It seems to create a new mmc window with no snapins loaded, rather than get the existing one with snapins loaded that I want.
Any advice? Am I just totally off base here, using completely the wrong command, or is there some simple change that I can make to fix this?
Edit:
Is there some weird workaround way I could achieve this, like storing an object to a temporary file so i can at least reuse it through a single session.
I'm in a weird situation where I am trying to add functionality to a powershell script and couldn't find a way to do it directly in powershell, so i'm setting up a vbscript to do one piece of it and calling the vbscript from powershell. I already had to do a lot of research to figure out how to do it in vbscript(and i'm still not sure about all of it) so i guess before i go any further, I'll try to figure out if this is even viable(in vbscript or c# or c++ or any other language someone could suggest)...
What i want to do, overall, is check if an MMC window is open that contains a DHCP snapin. If so, assign it to a variable. If not, create one.
Then it will read from a csv or txt file, and use the values to determine what node to navigate to within the snapin(DHCP>ServerName>IPv4>ScopeName>Scope Options).(I've mostly solved this part in vbscript, but don't know how to do it in C++ or C#)
Finally, I need to be able to execute a right-click menu item to "configure options", navigate the tabs of the popup that comes up, enter a value, and apply the changes/hit ok to close the popup. Worst case, If I can't do it "normally" by actually sending commands to the objects themselves, this part I can do with imitating keystrokes, but i don't want to do that if it's avoidable because it's sloppy.
Then, I basically will just need to somehow alert the powershell script that i'm "finished" so it can continue, or give an alert if there's an error.
I'm not asking anyone to walk me through all this, I just want to know if any of those steps aren't viable as i've described them, especially if I'm going to have to switch to c++ or c# to achieve the first part and therefore relearn the commands needed.
... and only create a new object IF there's not one open already ...
No, this is not possible in VBS, you need to do
Dim objMMC
Set objMMC = WScript.CreateObject("MMC20.Application")
if I create a new object every time the script runs, it will massively delay my overall script
In this case is the VBS the wrong language, you need to use C# or C++ executable.
What will happen if two different
programs try to write to the same
file simultaneously?
Will one of the programs experience
a file lock error?
How should programs be designed to
handle this scenario?
When the second app (or thread) try to open the file for writing it would throw IO exception.. simple..
say you have user A and user B, what you can do is, let both of them modify the content, there will be a small difference in time however "simultaneous" you want it to be, so check which user has "submitted" the changes first, save those changes and prompt a smart message to the next user saying "file has been updated, check changes before.. blah blah".
Use FileLock to avoid IO Exception when file is being accessed by multiple threads.
To restrict the scope, let assume we are in Windows world only.
Also assume we don't want to play with permission policy.
Is it possible for us to create a file that cannot be copied?
Thank you in advance.
"Trying to make digital files uncopyable is like trying to make water not wet." ~ Bruce Schneier
No. You can't create a file that a SYSADMIN can't copy. You could encrypt it, though.
Well, how about creating a file that uses up more than 50% of the total space on that machine and that is not compressible?
For instance, let us assume that you want to save a boolean (true or false) in such a fashion.
Depending on its value, you could then write a bit stream of ones or zeroes and encrypt said stream using some kind of encryption algorith, such as AES in CBC mode. This gives you the added advantage of error correction. Even in case of massive data corruption, you should be able to recover your boolean by checking whether ones or zeroes are prevalent in the decrypted stream.
In that case you cannot copy it around (completely) on the machine...
Of course, any type of external memory that can be added to the system would pose a problem in this scenario. But the file would be already encrypted, so don't worry about it too much...
Any file that can be read can have its contents written to another location (such as another file, i.e. copied).
The only thing you can do is limit who/what can read the file.
What is the motivation behind? If it is a read-only file, you can have it as embedded resources within your assembly.
Nice try, RIAA.
But seriously, no you can not. It is always possible to copy, you can just make it it more difficult for people to make sense of the file or try to hide it using like encryption. Spotify does it.
If you really try hard thou, you cold make a root-kit for windows and use it to prevent windows from even knowing about the file and also prevent copies. The file will still be there and copy-able by other tools, or Linux accessing the ntfs.
If in a running process you open a file and hold an exclusive lock, then other processes cannot read the file until you close the handle or your process terminates. However, as admin you could forcibly remove the lock handle.
Short answer: No.
You can, of course, use security settings to limit who can read the file. But if someone can read it, then they can copy it. Even if you found some operating system trick to disable "ordinary" copying, if someone can read the file, they can extract the contents, store it in memory, and then write it somewhere else.
You can encrypt the contents so it's only useful to your own program, that knows how to decrypt it.
That's about it.
When using Windows 7 to copy some files from a hard drive, certain files popped up a message saying they could not be copied in their entirety; certain data would be omitted from the copy. I suspect that had something to do with slack space at the end of the files, though I thought the message was curious. I would have expected the copy operation to just ignore the slack space.
If you are running old (OLD) versions of windows, there are certain characters you can put in the filename that make it invalid, not listed in folders, etc. They were used a lot in the old pub ftp days of filesharing ;)
In the old DOS days, you used to be able to flag disk sectors as bad and still read from them. This meant the OS ignored the sector in question but your application would know where to look and be able to get the data. Not sure this would work these days.
Another old MS-DOS trick was to put a space character in the middle of the filename (yes, spaces were valid characters for filenames). Since there was no method on the command line to escape a space, the file couldn't be copied using the DOS commands.
This answer is outside Windows so yeah
Dont know if its already been said but what about a file that is an inseperable part of the firmware so that it is always on AND running, perhaps it has firmware that generates a sequence that is required for the other . AN incedental effect of its running is to prevent any 80% or more of its code from being replicated. Lets say its on an entirely different board, protected by surge protectors, heavy em proof shielding and anything else required to make it completely unerasable.
If its possible to make a program that is ALWAYS on and running as long as the copying software is running then yes.
I have another way and this IS with windows. I will come to your house and give you a disk, i will then proceed to destroy every single computer you put the disk into. This doesnt work on XP
Well technically you could create and write to a write-only network share.
I need to create a new process with redirected standard error stream to some file. The code from which child process is being created has no console available, so there are cases when GetStdHandle(any) will return 0. Child process will try to duplicate all of its standard IO handles for some reason (source code for child process is unavailable) so all of it's handles should be valid.
So I need to run that process in the same manner as it's can be ran from the console with:
someproc <nul >nul 2>err
I see some ways for this:
1. Create two pair of pipes. This is possibly good solution, but it will be too complex for me.
2. Open "nul" file with CreateFile("nul", ...) function call. No file is being created by this call, but this looks weird too me.
3. Use INVALID_HANDLE_VALUE. This works too, but I think there can be different problems with another child processes.
I believe there are better ways.
As originally phrased, you have already answered your own question. To open a "nul" file, you simply specify "nul" when you call CreateFile. It only looks weird because hardly anyone ever uses that file name. (I don't see it used nearly as often as I see /dev/null.) It's perfectly valid, though.
But if you've found that Invalid_Handle_Value works, too, then go ahead and use that instead. It's certainly easiest. I wouldn't have expected it to work, initially, since I wouldn't expect it to be duplicable.
Yes, "nul" is doing what you think. If you move to unix, it will be "/dev/null". The funky name is a holdover from DOS days, along with "prn" and "com1", etc.
Using INVALID_HANDLE_VALUE with DuplicateHandle is improper: the documentation states that you need PROCESS_DUP_HANDLE access right on the handle. You don't have that righton INVALID_HANDLE_VALUE. Device NUL (symbolic link to /device/null) will work fine, though.