5 ms·

What is the important of distinguishing between the first file and files that follow it? Why not FindFile()?

jstimpfle 8y ago
Is there such a thing? What does it do? I can only find a perl implementation that seems to use FindFirstFile() / FindNextFile().
- humblebee 8y ago
  No, it was a question. Edit: I should clarify. It was a low effort question to another low effort question. I should state that I have no experience with the API in question. I was just asking a question of the difference between the two, and the poster above me answer in another reply that the answer is that FindFirstFile is used to initialize / reset the query, where FindNextFile is use to continue the query. To further answer the question I was replying to above, I think another function that could be paired with a hypothetical FindFile would be a method to initialize the query. I do not know what would be a better API.
  - jstimpfle 8y ago
    > To further answer the question I was replying to above, I think another function that could be paired with a hypothetical FindFile would be a method to initialize the query. This is the obvious and correct way to do it, and it's the way it's done in POSIX with opendir() / readdir().
magicalhippo 8y ago
How would FindFile() work then? As far as I can see, either you have some separate call to initialize the find handle (just like FindFirstFile does), or you pass the directory/filename mask redundantly over and over again, introducing the potential for suddenly calling it with an already initialized find handle but with a different directory.
- blattimwind 8y ago
  The classic UNIX approach would of course be making FindFile non-reentrant and not thread-safe either, then later adding a FindFile_r which takes an void* * where FindFile_r will store some intermediate state that you need to free yourself except when an error occured, because when you free it then you get a double free. (However, not all UNIX systems have FindFile_r, and some of those instead have FindFile2 with slightly different semantics).
  - jstimpfle 8y ago
    You are snarky, but I don't think it's warranted. Any examples of non-reentrant or thread-unsafe system calls in POSIX? There are a few library calls that have a cousin with an _r suffix in POSIX, but these are not system interfacing calls. Just don't use them if they don't match your requirements. Most of them aren't even non-reentrant or thread-unsafe, but simply lack an additional parameter for some use cases (the use cases mostly come when you program in object-oriented style). The one offender (not a system call, either) that I know from the top of my head is strtok() which is of course terrible, but why would you use it?
    - Someone 8y ago
      ”There are a few library calls that have a cousin with an _r suffix in POSIX, but these are not system interfacing calls.” Neither are most Windows functions. FindFirstFile, for example, is defined in kernel32.dll, and calls through to ntdll.dll, and eventually makes system calls such as NtOpenDirectoryObject and NtQueryDirectoryObject. What IMO matters is the usability of the stable API. It doesn’t matter whether that is the kernel interface or not.
      - jstimpfle 8y ago
        Yes. The distinction I made was meant to be between calls that end up calling into the system and ones that do not (like strtok()). I agree with what you say and my statement was exactly that the stable APIs into the system offered by POSX are mostly unproblematic.
wongarsu 8y ago
In theory there could be some FindFiles() that just returns an array of files. But how would you handle the memory to pass that data? The convention is that the caller allocates and owns the memory (for example you pass FindFirstFile a FIND_DATA structure to write the result into). But you don't know in advance how many files FindFiles() will return. It's not even trivial to have another API that tells you how many files FindFiles will return, because between two API calls files can be created and deleted by anyone on the system. The other option is to allocate some space, and if it wasn't enough ask for the rest of the data. And that's basically what FindFile() and FindNextFile() implement.

Is there such a thing? What does it do? I can only find a perl implementation that seems to use FindFirstFile() / FindNextFile().

humblebee 8y ago
No, it was a question. Edit: I should clarify. It was a low effort question to another low effort question. I should state that I have no experience with the API in question. I was just asking a question of the difference between the two, and the poster above me answer in another reply that the answer is that FindFirstFile is used to initialize / reset the query, where FindNextFile is use to continue the query. To further answer the question I was replying to above, I think another function that could be paired with a hypothetical FindFile would be a method to initialize the query. I do not know what would be a better API.
- jstimpfle 8y ago
  > To further answer the question I was replying to above, I think another function that could be paired with a hypothetical FindFile would be a method to initialize the query. This is the obvious and correct way to do it, and it's the way it's done in POSIX with opendir() / readdir().

magicalhippo 8y ago

How would FindFile() work then? As far as I can see, either you have some separate call to initialize the find handle (just like FindFirstFile does), or you pass the directory/filename mask redundantly over and over again, introducing the potential for suddenly calling it with an already initialized find handle but with a different directory.

blattimwind 8y ago
The classic UNIX approach would of course be making FindFile non-reentrant and not thread-safe either, then later adding a FindFile_r which takes an void* * where FindFile_r will store some intermediate state that you need to free yourself except when an error occured, because when you free it then you get a double free. (However, not all UNIX systems have FindFile_r, and some of those instead have FindFile2 with slightly different semantics).
- jstimpfle 8y ago
  You are snarky, but I don't think it's warranted. Any examples of non-reentrant or thread-unsafe system calls in POSIX? There are a few library calls that have a cousin with an _r suffix in POSIX, but these are not system interfacing calls. Just don't use them if they don't match your requirements. Most of them aren't even non-reentrant or thread-unsafe, but simply lack an additional parameter for some use cases (the use cases mostly come when you program in object-oriented style). The one offender (not a system call, either) that I know from the top of my head is strtok() which is of course terrible, but why would you use it?
  - Someone 8y ago
    ”There are a few library calls that have a cousin with an _r suffix in POSIX, but these are not system interfacing calls.” Neither are most Windows functions. FindFirstFile, for example, is defined in kernel32.dll, and calls through to ntdll.dll, and eventually makes system calls such as NtOpenDirectoryObject and NtQueryDirectoryObject. What IMO matters is the usability of the stable API. It doesn’t matter whether that is the kernel interface or not.
    - jstimpfle 8y ago
      Yes. The distinction I made was meant to be between calls that end up calling into the system and ones that do not (like strtok()). I agree with what you say and my statement was exactly that the stable APIs into the system offered by POSX are mostly unproblematic.

wongarsu 8y ago

In theory there could be some FindFiles() that just returns an array of files. But how would you handle the memory to pass that data? The convention is that the caller allocates and owns the memory (for example you pass FindFirstFile a FIND_DATA structure to write the result into). But you don't know in advance how many files FindFiles() will return. It's not even trivial to have another API that tells you how many files FindFiles will return, because between two API calls files can be created and deleted by anyone on the system. The other option is to allocate some space, and if it wasn't enough ask for the rest of the data. And that's basically what FindFile() and FindNextFile() implement.