I got some problem with using FindFirstFile/FindNextFile. As I know it returns a handle but I'm not capable to use it with CreateFileMapping/ReadFile because value of returned handle is different than returned from CreateFile. First question: What's the difference between these two handles and the second: is it possible to convert this handle? My only idea is to get the file name and than use CreateFile.
Regards
What's the difference between these two handles
The first one is search handle. Underneath, there's an iterator reading the directory entry in the file system.
The second one is an iterator reading the file content. The file may even be on another volume than the directory entry you've used to locate it. To learn more about that, google "B-Tree" and then "NTFS"
get the file name and than use CreateFile
Yes, but you need to combine directory + file name. I usually call PathAppend API (CPathT::Append, to be precise) to do that.
Related
Are there any rules for file extensions? For example, I wrote some code which reads and writes a byte pattern that is only understood by that specific programm. I'm assuming my anti virus programm won't be too happy if I give it the name "pleasetrustme.exe"... Is it gerally allowed to use those extensions? And what about the lesser known ones, like ".arw"?
You can use any file extension you want (or none at all). Using standard extensions that reflect the actual type of the file just makes things more convenient. On Windows, file extensions control stuff like how the files are displayed in Windows Explorer and what happens when you double click on it.
I wrote some code which reads and writes a byte pattern that is only
understood by that specific programm.
A file extension is only an indication of what type of data will be inside, never a guarantee that certain data formatted in a specific way will be inside the file.
For your own specific data structure it is of course always best to choose an extension that is not already in use for other file formats (or use a general extension like .dat or .bin maybe). This also has the advantage of being able to use an own icon without it being overwritten by other software using the same extension - or the other way around.
But maybe even more important when creating a custom (binary?) file format, is to provide a magic number as the first bytes of that file, maybe followed by a file header structure containing a version number etc. That way your own software can first check the header data to make sure it's the right type and version (for example: anyone could rename any file type to your extension, so your program needs to have a way to do some checks inside the file before reading the remaining data).
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.
Due to some brain damage, (either in windows or in me), there appears to be no API to get the size of a windows resource produced by LoadResource. The return type is HANDLE, but it's not a real handle, and GlobalSize does not work on it.
So absent the API, I need to embed my blobs in some simple format that will
wrap them with their length. Surely there must be a utility somewhere that
rewrites a file as a length, followed by the contents of the file, or some
such trivial encoding.
Not an answer to your question as to a helper for the work-around, but the API is not missing.
When you called LoadResource, you passed in the module handle and a HRSRC handle.
If you call SizeOfResource with the same arguments, it returns the size of the resource.
I remember there was a WinAPI function which copied the "date modified" property of the previous file which was replaced with it or something like that? Perhaps anyone can tell me about it?
The problem occured when you used that function very frequently.
This is ReplaceFile (Windows 2000 and up):
The ReplaceFile function combines
several steps within a single
function. An application can call
ReplaceFile instead of calling
separate functions to save the data to
a new file, rename the original file
using a temporary name, rename the new
file to have the same name as the
original file, and delete the original
file. 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
Encryption
Compression
Named streams not already
in the replacement file
Not too clear exactly what you want, but it seems your after SetFileTime to edit and GetFileTime to copy, combining the two you can do exactly as 'described/wanted'