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.
Related
Before merging a list of files, I grab their assembly permission using PdfReader:
long PdfReader.getPermissions()
and check the result using PdfEncryptor:
static boolean PdfEncryptor.isAssemblyAllowed(int permissions)
As you see the first line of code returns a long, while the second expects an int. If I just cast the long to an int, the method PdfEncryptor.isAssemblyAllowed always returns true. But later in the code when I go to perform the actual merging, an error is thrown saying I lack the necessary permissions.
Is this a bug, or am I missing something in how the permission flag should be used?
As a workaround one can use the method
public boolean PdfReader.isOpenedWithFullPermission()
and don't merge if this returns false. But this might be over cautious.
Neither iText 5 nor iText 7 checks the detail permissions when operating on PDFs. When they do check permissions for some operation, they only call PdfReader.isOpenedWithFullPermission().
The reason for this may be that the individual permissions originally have been designed to match specific GUI operations in Adobe Acrobat which do not directly match specific API calls of iText.
Thus, if you regularly have to deal with documents with restricted permissions, consider setting the UnethicalReading flag, checking the appropriate flags in your code, and rejecting documents only according to that check.
As an aside, your current check is based on isAssemblyAllowed. The flag is specified as:
Assemble the document (insert, rotate, or delete
pages and create document outline items or thumbnail images), even if bit 4 [Modify the contents of the document] is clear.
Thus, this does not really match the permission you are looking for as it essentially refers to the target document (i.e. the merge result) while you test the source document. More appropriately, therefore, would be testing isCopyAllowed.
Question
Is there any way to write a custom function that uses the same pattern as the Open function? Including the fluff keywords like For and As?
Background
I am working on migrating an old VB6 project to use online data via an API, as a first step I'd like to replace all instances of
Open SomeFilename For Binary Access Read As #39
With a custom OpenOnline function
OpenOnline SomeFilename For Binary Access Read As #39
But I do not know how to indicate those keywords are necessary when creating a function, or even if it's possible to do so.
Function openOnline(FileName As String) [For] (Optional Access As AccessType = Binary Access) [As] (Optional FileNumber As Integer) As Boolean
' Do the work of connecting to the online data equivalent of FileName with that access type
End Function
Qualifiers
I understand that these keywords are nonsensical in the context of an OpenOnline function. I also understand that I can use regular expressions to find and replace the syntax to remove keywords like "For" and "Read".
There are hundreds of thousands of instances of this Open function, the Put and Get functions and a few other file related functions, I realize that long term the correct solution is changing the mechanisms fundamentally to use online paradigms, and that work is in progress- on schedule to be completed with about 4 months of effort at the rate things are going.
Bonus Question
Secondarily, is there any way for me to pass a "User Defined Type" variable to the new Put/Get replacements in a way that I can access their fields directly without knowing the type beforehand? (I understand that variants are only available for .cls classes or public user defined types in dlls, neither of which apply in this situation)
As for 1), you can get close but you can't exactly replicate the VB Open statement. Which means you won't get around of some search & replace passes for the current Open statement lines with your newly created one.
For 2), can you illustrate that with an example? I'm trying to think of a situation where you know the UDT member's name in advance, but not its type.
That said, perhaps looking at VB's VarType function gives you an idea for solving that.
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().
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.
Which should be used in which scenarios?
Does ldap_search_init_page() also support to search with DirSync?
FYI:
http://msdn.microsoft.com/en-us/library/aa366972(v=vs.85).aspx
http://msdn.microsoft.com/en-us/library/aa366973(v=vs.85).aspx
Thanks.
When you make a search on a Directory, it's not like in a database. The Directory is not supposed to give you back all the responses for your search (most of the time you not need them like in a google search). Directory servers assume good performances this way.
ldap_search_ext_s initiate a search, it's synschronous, and you can specify options like LDAP_OPT_SIZELIMIT and LDAP_OPT_TIMELIMIT (if they are available on the server). This API returns search result (if exists), and maybe more search result than a normal search.
With ldap_search_init_page() you initiate a kind of 'find fist', 'find next' search. This API does not return search result, but a structure tou can use in ldap_get_next_page, ldap_get_next_page_s, ldap_get_paged_count and ldap_search_abandon_page. ldap_get_next_page and ldap_get_next_page_s can return search result and the second one synchronously. This way allow you to retreive ALL the results for a search, be carefull it's not the way a normal LDAP search is supposed to work, this is bad on the performance point of view.