5 ms·

You chose a very poor example, since you can most definitely open files in VB, and therefore the "File.Exists()" function would at worse be comprised of a excep

You chose a very poor example, since you can most definitely open files in VB, and therefore the "File.Exists()" function would at worse be comprised of a exception handler (on error ...) and a open call, as in many other languages. No need to import OpenFile for sure.

Brian_K_White 2y ago
But then you may have actually opened the file.
- ahoka 2y ago
  But then the only way to make sure that you can open a file is to actually open it.
  - Brian_K_White 2y ago
    You don't use exists and then open a file. If you actually want to open a file, you open it or fail. You don't check if it's ok and then do it, you do it and then check if it failed. exists followed by open is a pointless exists because anything can happen in between. Conversely, if you are neither the producer nor consumer of the file at this time, you don't want to actually open it just as a way to stat it, because actually opening it updates it's access time and interferes with the actual consumer(s). Even read-only non-exclusive.
    - gus_massa 2y ago
      You can use it as an improvised lock.
      - Brian_K_White 2y ago
        How do you impliment this lock? You use an atomic operation. Which atomic operation? You try to open the file in exclusive mode.
        gus_massa 2y ago
        Create the file to lock and delete to unlock. I'm not sure if there are corner cases.
        Brian_K_White 2y ago
        I misread the comment first, I missed the word "it". I thought you were saying you could use a seperate lock to guard the time between exist() and open(), which is possible but silly. Now I'm not sure what you meant. Is "it" exists() or open()? You can use open() as a lock for other things. It doesn't need any other locks itself. You can't use exists() as a lock. Or, I guess you are saying one process can open the file and others can merely check exists()? Yes depending on what the purpose was, what you intend to do with the results of exists(), because it isn't true any more the instant after exists() returns, only while exists() is actually running. That makes it sound useless and therefor what is the problem that VB6 didn't have it? That might very well be why it was omitted. But you do need some form of stat(), a way to get info about files without affecting them in any way. A process needs to be able to watch a files access time to know if it's been accessed yet, or when last, without that very observation changing the access time or making the file appear open()ed to other processes that may care about that. Even being opened read-only andbnon-exclusive is still opened. Another process may need to know that it has eclusive access or else it can't do it's thing, so it will fail it's own open() exclusive. Even if the other process retries and open succeeds a few cycles later, changing the access time breaks the process that's waiting for the file to be accessed by it's actual consumer so it can be automatically deleted for example, or simply logged the fact that the customer has downloaded the edi file, the remote client/browser has loaded the temp file, someone somewhere has accessed super secret file, etc. (setting aside that these days at least on *ix you frequently disable atime updates in the filesystem altogether and just do not build anything on top of that any more for performance and flash write life reasons. But I have processes that use it only in tmpfs in ram even while it's off for the real filesystem.)
        gus_massa 2y ago
        I used something like that 20 years ago, so I forgot the details. Perhaps I just tried to create the file without checking if it exist(?????). The code is long gone.
- AshamedCaptain 2y ago
  But if you rely on these subtleties this is hardly a "basic feature" that the language is lacking. In fact, I imagine File.Exists()/OF_EXISTS also opens the file (then immediately closes it).
  - Brian_K_White 2y ago
    It better not! If you actually open a file, you update it's access time, and you interfere with the process that should actually open the file. Those both break perfectly simple business logic.
    - deleted 2y ago
      [deleted]
    - AshamedCaptain 2y ago
      The documentation for OF_EXISTS literally says it will open then close it. I leave to your imagination whether this updates the (very poorly defined) access time or not, but for sure you "interfere" with other processes... If you want to get the access time, why don't you just query the access time? Which is likely the only thing almost universally guaranteed not to change it... And I'm sure VB6 has an API for that, considering that VBA had a global API for it (FileDateTime). (Which is, btw, yet another way to one-line check if a file exists).
      - Brian_K_White 2y ago
        Did you confuse the file with it's containing directory? The way you probably did in your now-deleted comment claiming that stat() updated atime? Citation needed. https://learn.microsoft.com/en-us/dotnet/api/system.io.file.exists?view=net-8.0 https://learn.microsoft.com/en-us/dotnet/api/system.io.file.... doesn't warn of any such thing.
        deleted 2y ago
        [deleted]
        2y ago
coliveira 2y ago
I believe some people used that monster version because VB had simple libraries that didn't allow many options. Anything more complex required you to go down the Win32 rabbit hole. And that was the main weakness of VB, it was such a simple language that you didn't have many options to do something more complex than going straight to Win32.
- AshamedCaptain 2y ago
  It is a very different thing to claim "the language doesn't allow simple things such as checking for a file's existence" (which is false, the language allows many ways to do so) than to claim "the language doesn't have many options, but allows you to interop with the entire win32 API if you need to". The first is a valid if only false complain; the second reads to me not as a complain, but as a feature.
  - jasode 2y ago
    >to claim "the language doesn't allow simple things such as checking for a file's existence" (which is false, That's not what I wrote. I said there's no _built-in_ way to check existence of the file. A reasonable interpretation of "built-in" is for an obvious named function such as "File.exists()" _without_ cobbling together extra workarounds and hacks -- whether those workarounds include re-purposing other VB built-in functions with On Error ... or using Win32 interop. > in VB, [...] would at worse be comprised of a exception handler (on error ...) That's an example of what I meant of not being built-in to VB. I should have been more clear. We were using different meanings of "builtin". In any case, the following "pure" VB code to check for file existence is not found on Google or Bing search but I still have it from my 1995 archives and copied it here. It has many lines of code (instead of a simple "one-liner") because it tries to cover all the edge cases. And yet with all that defensive code, there's still a hidden timebomb of a bug in it. Can anyone spot it? The code is unmodified from Visual Basic Programmer's Journal. In contrast, the alternative using Win32 interop with OF_EXISTS doesn't have the bug. Dim strTestFilename As String strFilename = Trim(strFilename) ' To avoid problem with known bug, don't pass root directory to ' the Name function Select Case Right$(strFilename, 1) Case "\": strExistsFilename = "Root": Exit Function Case "\.": strExistsFilename = "Root": Exit Function Case "\..": strExistsFilename = "Root": Exit Function End Select On Local Error Resume Next ' Enable error trapping for Name function Name strFilename As strFilename ' A trick to see if filename/path is good ' Now check the resulting err code of the Name function Select Case Err Case 5 ' Illegal function call Case 53 ' File not found Case 58 ' File exists (maybe) strTestFilename = Dir$(strFilename) If Len(strTestFilename) Then strExistsFilename = "" ' It's a file Exit Function Else strExistsFilename = "Dir" ' It's a directory Exit Function End If Case 64 ' Bad filename Case 68 ' Device unavailable Case 71 ' Disk not ready Case 75 ' Access denied Case 76 ' Path not found End Select My point was that C# builtin File.Exists() is a lot simpler than that.

Brian_K_White 2y ago

But then you may have actually opened the file.

ahoka 2y ago
But then the only way to make sure that you can open a file is to actually open it.
- Brian_K_White 2y ago
  You don't use exists and then open a file. If you actually want to open a file, you open it or fail. You don't check if it's ok and then do it, you do it and then check if it failed. exists followed by open is a pointless exists because anything can happen in between. Conversely, if you are neither the producer nor consumer of the file at this time, you don't want to actually open it just as a way to stat it, because actually opening it updates it's access time and interferes with the actual consumer(s). Even read-only non-exclusive.
  - gus_massa 2y ago
    You can use it as an improvised lock.
    - Brian_K_White 2y ago
      How do you impliment this lock? You use an atomic operation. Which atomic operation? You try to open the file in exclusive mode.
      - gus_massa 2y ago
        Create the file to lock and delete to unlock. I'm not sure if there are corner cases.
        Brian_K_White 2y ago
        I misread the comment first, I missed the word "it". I thought you were saying you could use a seperate lock to guard the time between exist() and open(), which is possible but silly. Now I'm not sure what you meant. Is "it" exists() or open()? You can use open() as a lock for other things. It doesn't need any other locks itself. You can't use exists() as a lock. Or, I guess you are saying one process can open the file and others can merely check exists()? Yes depending on what the purpose was, what you intend to do with the results of exists(), because it isn't true any more the instant after exists() returns, only while exists() is actually running. That makes it sound useless and therefor what is the problem that VB6 didn't have it? That might very well be why it was omitted. But you do need some form of stat(), a way to get info about files without affecting them in any way. A process needs to be able to watch a files access time to know if it's been accessed yet, or when last, without that very observation changing the access time or making the file appear open()ed to other processes that may care about that. Even being opened read-only andbnon-exclusive is still opened. Another process may need to know that it has eclusive access or else it can't do it's thing, so it will fail it's own open() exclusive. Even if the other process retries and open succeeds a few cycles later, changing the access time breaks the process that's waiting for the file to be accessed by it's actual consumer so it can be automatically deleted for example, or simply logged the fact that the customer has downloaded the edi file, the remote client/browser has loaded the temp file, someone somewhere has accessed super secret file, etc. (setting aside that these days at least on *ix you frequently disable atime updates in the filesystem altogether and just do not build anything on top of that any more for performance and flash write life reasons. But I have processes that use it only in tmpfs in ram even while it's off for the real filesystem.)
        gus_massa 2y ago
        I used something like that 20 years ago, so I forgot the details. Perhaps I just tried to create the file without checking if it exist(?????). The code is long gone.
AshamedCaptain 2y ago
But if you rely on these subtleties this is hardly a "basic feature" that the language is lacking. In fact, I imagine File.Exists()/OF_EXISTS also opens the file (then immediately closes it).
- Brian_K_White 2y ago
  It better not! If you actually open a file, you update it's access time, and you interfere with the process that should actually open the file. Those both break perfectly simple business logic.
  - deleted 2y ago
    [deleted]
  - AshamedCaptain 2y ago
    The documentation for OF_EXISTS literally says it will open then close it. I leave to your imagination whether this updates the (very poorly defined) access time or not, but for sure you "interfere" with other processes... If you want to get the access time, why don't you just query the access time? Which is likely the only thing almost universally guaranteed not to change it... And I'm sure VB6 has an API for that, considering that VBA had a global API for it (FileDateTime). (Which is, btw, yet another way to one-line check if a file exists).
    - Brian_K_White 2y ago
      Did you confuse the file with it's containing directory? The way you probably did in your now-deleted comment claiming that stat() updated atime? Citation needed. https://learn.microsoft.com/en-us/dotnet/api/system.io.file.exists?view=net-8.0 https://learn.microsoft.com/en-us/dotnet/api/system.io.file.... doesn't warn of any such thing.
      - deleted 2y ago
        [deleted]
      - 2y ago

coliveira 2y ago

I believe some people used that monster version because VB had simple libraries that didn't allow many options. Anything more complex required you to go down the Win32 rabbit hole. And that was the main weakness of VB, it was such a simple language that you didn't have many options to do something more complex than going straight to Win32.

AshamedCaptain 2y ago
It is a very different thing to claim "the language doesn't allow simple things such as checking for a file's existence" (which is false, the language allows many ways to do so) than to claim "the language doesn't have many options, but allows you to interop with the entire win32 API if you need to". The first is a valid if only false complain; the second reads to me not as a complain, but as a feature.
- jasode 2y ago
  >to claim "the language doesn't allow simple things such as checking for a file's existence" (which is false, That's not what I wrote. I said there's no _built-in_ way to check existence of the file. A reasonable interpretation of "built-in" is for an obvious named function such as "File.exists()" _without_ cobbling together extra workarounds and hacks -- whether those workarounds include re-purposing other VB built-in functions with On Error ... or using Win32 interop. > in VB, [...] would at worse be comprised of a exception handler (on error ...) That's an example of what I meant of not being built-in to VB. I should have been more clear. We were using different meanings of "builtin". In any case, the following "pure" VB code to check for file existence is not found on Google or Bing search but I still have it from my 1995 archives and copied it here. It has many lines of code (instead of a simple "one-liner") because it tries to cover all the edge cases. And yet with all that defensive code, there's still a hidden timebomb of a bug in it. Can anyone spot it? The code is unmodified from Visual Basic Programmer's Journal. In contrast, the alternative using Win32 interop with OF_EXISTS doesn't have the bug. Dim strTestFilename As String strFilename = Trim(strFilename) ' To avoid problem with known bug, don't pass root directory to ' the Name function Select Case Right$(strFilename, 1) Case "\": strExistsFilename = "Root": Exit Function Case "\.": strExistsFilename = "Root": Exit Function Case "\..": strExistsFilename = "Root": Exit Function End Select On Local Error Resume Next ' Enable error trapping for Name function Name strFilename As strFilename ' A trick to see if filename/path is good ' Now check the resulting err code of the Name function Select Case Err Case 5 ' Illegal function call Case 53 ' File not found Case 58 ' File exists (maybe) strTestFilename = Dir$(strFilename) If Len(strTestFilename) Then strExistsFilename = "" ' It's a file Exit Function Else strExistsFilename = "Dir" ' It's a directory Exit Function End If Case 64 ' Bad filename Case 68 ' Device unavailable Case 71 ' Disk not ready Case 75 ' Access denied Case 76 ' Path not found End Select My point was that C# builtin File.Exists() is a lot simpler than that.