I'd like to open up a file by ID and then use the resulting handle in the Win32 API BackupRead()
Is this possible? I'm not certain if its 'okay' to use handles that come from NtCreateFile() in other Win32 APIs?
For example, may I do this
NtCreateFile(&handle, ..., FILE_OPEN_BY_FILE_ID, ....)
BackupFile(handle, ....)
I'm somewhat bothered by using NtCreateFile, it's well documented on MSDN but they also mention compatibility problems could occur
Any ideas?
I'm not sure I have 100% understood what your problem is, and I don't know any function named BackupFile().
If what you want is reusing handles from NTCreateFile() with BackupRead(), it should be perfectly fine to do so, provided the file handle was opened with the right flags & permissions.
Be sure to call NTCreateFile with the FILE_OPEN_FOR_BACKUP_INTENT flag:
NtCreateFile(&handle, ..., FILE_OPEN_BY_FILE_ID|FILE_OPEN_FOR_BACKUP_INTENT, ....)
If you plan to pass the resulting handle to BackupRead().
Related
Problem: we are wanting to use SonarJS but much of our old Javascript code uses functions from the Microsoft ASP.Net framework (and the MS AjaxToolkit). As such we have a couple of hundred occurrences of the error "XXX" does not exist. Change its name or declare it so that its usage doesn't result in a "ReferenceError". (where XXX is Sys, Type, $get etc.).
I appreciate that I could suppress these by specifying them all in the sonar.javascript.globals property (as per the Elena Vilchik's answer to this question ) but it feels like what I really want to do is to add my own bespoke entries in sonar.javascript.environments (called msajax and msajaxtoolkit say). Then I could be more precise about when to include / exclude these globals.
So I guess I would like to know whether defining my own environment is supported or if there is a more elegant solutions overall.
Thanks in advance.
You are more than welcome to open pull request for https://github.com/SonarSource/sonar-javascript. Edit "javascript-frontend/src/main/resources/org/sonar/javascript/tree/symbols/globals.json" by adding new group/groups of names.
I have a search handle returned by FindFirstFile.
At a later point in my program I'd like to log some details about the search (ideally the search pattern or the directory being searched) but I only have the handle available to get at those details.
For good reasons (trust me) I don't want to store those information when the search is started so my only option is to somehow query the handle.
Does the Windows API provide any function to do that? Something like GetFilenameFromSearchHandle()
I assume FindFirstFile is implemented using NtQueryDirectoryFile which works on a regular file handle, so is there a way to get from search handle to underlying file handle?
Windows provides no such functionality. There is no way to start with just a search handle, and query for the original parameters passed to FindFirstFile. You will need to make a note of those parameters when you call FindFirstFile.
Is the ReplaceFile Windows API a convenience function only, or does it achieve anything beyond what could be coded using multiple calls to MoveFileEx?
I'm currently in the situation where I need to
write a temporary file and then
rename this temporary file to the original filename, possibly replacing the original file.
I thought about using MoveFileEx with MOVEFILE_REPLACE_EXISTING (since I don't need a backup or anything) but there is also the ReplaceFile API and since it is mentioned under Alternatives to TxF.
This got me thinking: Does ReplaceFile actually do anything special, or is it just a convenience wrapper for MoveFile(Ex)?
I think the key to this can be found in this line from the documentation (my emphasis):
The replacement file assumes the name of the replaced file and its identity.
When you use MoveFileEx, the replacement file has a different identity. Its creation date is not preserved, the creator is not preserved, any ACLs are not preserved and so on. Using ReplaceFile allows you to make it look as though you opened the file, and modified its contents.
The documentation says it like this:
Another advantage is that ReplaceFile not only copies the new file data, but also preserves the following attributes of the original file:
Creation time
Short file name
Object identifier
DACLs
Security resource attributes
Encryption
Compression
Named streams not already in the replacement file
For example, if the replacement file is encrypted, but the
replaced file is not encrypted, the resulting file is not
encrypted.
Any app that wants to update a file by writing to a temp and doing the rename/rename/delete dance (handling all the various failure scenarios correctly), would have to change each time a new non-data attribute was added to the system. Rather than forcing all apps to change, they put in an API that is supposed to do this for you.
So you could "just do it yourself", but why? Do you correctly cover all the failure scenarios? Yes, MS may have a bug, but why try to invent the wheel?
NB, I have a number of issues with the programming model (better to do a "CreateUsingTemplate") but it's better than nothing.
Somebody gave me a testing program to write records into the windows event log (but I don't have the sources). I understand the general way of writing and reviewing event log, but that program behaves very special in a way that I can write records, that have a source which does not exist.
There is not even a registry entry in .../eventlog/application, hence no formatting libs.
If I try that from my own code, I can write such a record but the Windows Event Viewer then always tells me something about "description cannot be found" (which is correct and I understand why that happens).
The question is now: Since that foreign test prog CAN do it, it must be possible somehow - but HOW?
Many thx!! :-)
OK, finally I found it (also, got the sources) - the prog creates the registry entry (probably happens when calling CreateEventSource()), it was just not visible until refreshing regedit :-|
And, it DOES register a formatting lib, only that it is something I cannot rely on: C:\Windows\Microsoft.NET\Framework64\v2.0.50727\EventLogMessages.dll
Or, can I?
Ah, here we go for an explanation:
Difference between EventLog.WriteEntry and EventLog.WriteEvent methods
So, I cannot, as I'm not using .Net ... :-|
Now, if I NOW send another event from MY prog (with the same, newly created source, as the foreign prog), I see it in the event viewer normally.
That means, WriteEntry() actually does not write a different/special type of evt log record containing the text directly (contrary to the standard method of writing just a msg catalog ID + params) but rather there must be some trick in the formatting lib to make the EventViewer apply some kind of "default" formatting.
Any ideas how I could accomplish this? Except just copying the EventLogMessages.dll above? :-)
OK, finally found an answer about this one in http://msdn.microsoft.com/en-us/magazine/cc163446.aspx
"This file is called EventLogMessages.dll, and it contains 65,536 event descriptions, each of which consists of the string "%1", a placeholder for whatever string you want to write"
I was hoping for something like "messageid=*" but that seems to be too simple :-|
But maybe somebody else is interested in whats happening here ...
Does anyone know a pure Win32 solution for renaming a file and only changing its capitalization, that does not involve intermediate renaming to a different name or special privileges (e.g. backup, restore).
Since the Win32 subsystem generally regards two file names differing only in capitalization as the same, I haven't been able to find any solution to the problem.
A test program I made with the MoveFile API seems to work. So does the rename command in cmd.exe. What have you tried, and what error are you getting?
This isn't relevant, but further testing shows that renaming a long filename in this way works but will change the short filename (alternating between ~1 and ~2 for example), incidentally.
Just use the normal MoveFile API. That call probably just turns into ZwSetInformationFile(..., FileRenameInformation,...) The docs for FILE_RENAME_INFORMATION states that you need DELETE access and the file can't be locked etc, but those restrictions will probably apply to other solutions also.
I do not believe there is a way to expose two files with identical names that differ only in spelling to the Win32 subsystem. Even if some how you were able to create these files, the most likely result would be that only one file would be accessible - defeating the purpose of staying soley in Win32.
If you want to go into the Native layer, you can create a file with NtCreateFile and InitializeObjectAttributes w/o OBJ_CASE_INSENSITIVE or you can pad the end with extra spaces (if you pad with extra spaces, the file will not be accessible from Win32 dos paths). See here: http://www.osronline.com/ddkx/kmarch/k109_66uq.htm . I'm pretty sure you were already aware but I included it incase you did not know.
So long as your file is not immediately needed by another program, you can use my solution.
When you rename the file, capitalize, and delete the last letter. Then rename again and return the letter.
:)