better way to check if file exists?

[Stuart McLachlan]

Wow, this debate is still going on? It was going on in 1998...

FindNextFile, I can post my function which has worked for 20 years if need be, but someone has a close version above.

Don't bother, now we have ISFILE()

[Scott Turchin]

Wow, this debate is still going on? It was going on in 1998...

FindNextFile, I can post my function which has worked for 20 years if need be, but someone has a close version above.

[Stuart McLachlan]

Del.

[Stuart McLachlan]

DIR$ CLOSE closes the search handle on the folder against which the DIR$ ("filespec") statement was issued. Until this search handle is closed, renames or deletes from that folder will fail, as will attempts to delete the the folder.

Really?
'

#COMPILE EXE
#DIM ALL

FUNCTION PBMAIN() AS LONG
    LOCAL wsFile AS WSTRING
    LOCAL strCOntent AS STRING
    LOCAL x,ff AS LONG
    'Build some test files
    strCOntent = "Something in the file"
    FOR x = 1 TO 10
        ff = FREEFILE
        OPEN "Test" & FORMAT$(x,"00") & ".dmo" FOR OUTPUT AS #ff
        PRINT #ff, strContent
        CLOSE #ff
    NEXT
   ? "check the contents of the folder, there should be 10 matching files there"
    ' iterate through the file
    wsFile = DIR$(EXE.PATH$ & "\Test*.dmo")
    WHILE wsFile > ""
        KILL wsFile           'delete from the folder while the DIR$() file handle is open
        wsFile = DIR$()
    WEND
    DIR$ CLOSE
    ? "check the contents of the folder!!! - Deleting the files worked while the DIR$() file handle was open
END FUNCTION
'

[Michael Mattias]

Please explain how DIR$ CLOSE addresses this issue (as you claim)

DIR$ CLOSE closes the search handle on the folder against which the DIR$ ("filespec") statement was issued. Until this search handle is closed, renames or deletes from that folder will fail, as will attempts to delete the the folder.

In what way is this code "silly" or "irresponsible" or a [misuse] of DIR$(NEXT)

I meant it was a misuse of DIR$ CLOSE, not a misuse of DIR$(NEXT). That's the way I read your post #24.

[Stuart McLachlan]

In my professional (even if retired) opinion, that kind of misuse of DIR$(NEXT) is, in a word, "silly." Ok, in a second word, "irresponsible" for any veteran programmer to make.

wstrFIlename = DIR$("*.bas")
WHILE wstrFileName > ""
    IF NOT FileExists(wstrBackupLocation" & wstrFilename THEN
        FILECOPY strFilename, wstrBackupLocation" & wstrFilename
    END IF
    wstrFilename = DIR$(NEXT)
WEND
DIR$ CLOSE

In what way is this code "silly" or "irresponsible" or a mususe of DIR$(NEXT)
As long as it does not use DIR$ in the FileExists function it is perfectly reasonable (although now that we have ISFILE(), we don't need a separate FileExists function
If the function FileExists uses DIR$ (which is the whole point of this thread). it is an issue.
This is exactly the issue which you agreed is real and claimed was addresses with DIR$ CLOSE.
Please explain how DIR$ CLOSE addresses this issue (as you claim)

[Stuart McLachlan]

Huh?
In my professional (even if retired) opinion, that kind of misuse of DIR$(NEXT) is, in a word, "silly." Ok, in a second word, "irresponsible" for any veteran programmer to make.

In my opinion (professional or otherwise) , you've completely lost the plot again. I suggest you read the previous posts in the thread for a change before making irrelevant comments. Specficially, read posts 6 - 8. and then rethink whether your coontention that DIR$() CLOSE addresses the issue WHICH YOU AGREED IS REAL!

I'll ignore the rest of your condescending, off topic comments.

[Michael Mattias]

Using DIR$ CLOSE also "throws off DIR$ (without filespec) continuity" in EXACTLY the same way that the code in Post #6 will
( i.e. if called in the middle of a loop containing DIR$() or DIR$(NEXT).)

Huh?

In my professional (even if retired) opinion, that kind of misuse of DIR$(NEXT) is, in a word, "silly." Ok, in a second word, "irresponsible" for any veteran programmer to make.

Did you also know disk file operations may fail if you call CLOSE in the middle of a loop with WRITE# and or LINE INPUT ?

How about using DIALOG SET TEXT following a DIALOG CLOSE?

The best way to look at DIR$() and DIR$ CLOSE is the same way you look at (file) OPEN and CLOSE, or DIALOG NEW / DIALOG END... PB statements always used as matched pairs. .. an "initiator" (DIR$(filespec)), DIALOG NEW), actions against the object just initiated (WRITE#, DIALOG SET COLOR), and a "terminator" action (CLOSE, DIALOG END)

MCM

[Stuart McLachlan]

Dave Navarro pre 2000.

FUNCTION exist(fname$) as DWORD
FUNCTION = Len( Dir$(fname$, 17) ) > 0
END FUNCTION

I can do it with the FindFirstFile method but Dave's old code works fine.

Lance Edmonds pointed out that that function was actually in Common32.bas in Samples back then.( see Post#6)
But it can cause problems. That is what started this thread back in 2001. See Tom Hamlin's post #7 and the OP's post #8.
That's no doubt why later versions of Common32.bas were changed to

FUNCTION Exist(FileSpec AS STRING) EXPORT AS INTEGER

    LOCAL fd    AS WIN32_FIND_DATA
    LOCAL hFind AS DWORD

    IF LEN(FileSpec) THEN
        hFind = FindFirstFile(BYCOPY FileSpec, fd)
        IF hFind <> %INVALID_HANDLE_VALUE THEN
            FindClose hFind
            FUNCTION = %TRUE
        END IF
    END IF

END FUNCTION

It's still there in the current Samples, even though ISFILE() now makes it redundant.

[Steve Hutchesson]

Dave Navarro pre 2000.

FUNCTION exist(fname$) as DWORD
  FUNCTION = Len( Dir$(fname$, 17) ) > 0
END FUNCTION

I can do it with the FindFirstFile method but Dave's old code works fine.

[Stuart McLachlan]

This issue - which is real - has been addressed by PB with the CLOSE option added to the DIR$ function.

CLOSE does not address this issue in any way..

Using DIR$ CLOSE also "throws off DIR$ (without filespec) continuity" in EXACTLY the same way that the code in Post #6 will
( i.e. if called in the middle of a loop containing DIR$() or DIR$(NEXT).)

[Michael Mattias]

Posts 7 and 8.
"The problem with using DIR$(filespec) in an EXIST function is,it throws off DIR$ (without filespec) continuity in the rest of your app."
and
"Thats persactly why I needed this..."

This issue - which is real - has been addressed by PB with the CLOSE option added to the DIR$ function.

I very much recommend using 'DIR$ CLOSE' after any use of DIR$ in your programs. Otherwise file operations against the folder in which the DIR$() function was called may be impacted.

This is essentially a "FindClose ()" WinAPI call against the search handle returned by FindFirstFile().

MCM

[Dale Yarker]

From PBWin 8.0x Help

GETATTR can also be used to verify the existence of a file or directory, taking advantage of the fact that ERR will be set if the file/directory does not exist. See the example below.

Still in 10's help.

From MSDN for FindFirstFileA function

If the function fails because no matching files can be found, the GetLastError function returns ERROR_FILE_NOT_FOUND.

Back to choice of PB or API

[Stuart McLachlan]

They didn't heed post 2.

GetAttr ?

Yep, but Post #3 and FindFirstFile was probably a better solution than causing a runtime error
Plus they were both posted at almost the same time and post #3 gave a usable function rather than a cryptic reference

[Dale Yarker]

They didn't heed post 2.

[Stuart McLachlan]

What did OP had against DIR$ ??

Posts 7 and 8.
"The problem with using DIR$(filespec) in an EXIST function is,it throws off DIR$ (without filespec) continuity in the rest of your app."
and
"Thats persactly why I needed this..."

Which could also be a problem in my Post #13
But straighforward use of ISFILE and ISFOLDER is not a problem.

[Dale Yarker]

Would you rely on them returing a full FileAttribute mask value?

No, GETATTR.

What did OP had against DIR$ ?? Just ISFILE now! (mentioned above, if you go through old and really posts above.

[Stuart McLachlan]

Yeap.

Added to the links you gave:
File Attribute Constants (WinNT.h) - Win32 apps | Microsoft Docs

"For a list of related APIs and topics, see the See Also section."
No mention of PathIsDirectory or PathIsDirectoryEmpty in that section.
Would you rely on them returing a full FileAttribute mask value?

I'd stick with a boolean (IsTrue or IsFalse or =0 or <>0) test if using those functions,

[Dale Yarker]

So he'd get the wrong result if the folder was not archived or was indexed or had any other attributes set (Hidden, System...) ?

Yeap.

Added to the links you gave:
File Attribute Constants (WinNT.h) - Win32 apps | Microsoft Docs

[Stuart McLachlan]

FILE_ATTRIBUTE_DIRECTORY = 16 (bit 4)
FILE_ATTRIBUTE_ARCHIVE = 32 (bit 5)
FILE_ATTRIBUTE_NOT_CONTENT_INDEXED = 8192 (bit 13)

16 OR 8192 = 8208
32 OR 8192 = 8224

An AND with his result variables from API calls would have given TRUE or FALSE answer

So he'd get the wrong result if the folder was not archived or was indexed or had any other attributes set (Hidden, System...) ?

Both of the API functions he is calling just return a BOOLEAN according to MS:
https://docs.microsoft.com/en-us/win...thisdirectorya
Return value
Type: BOOL
Returns (BOOL)FILE_ATTRIBUTE_DIRECTORY if the path is a valid directory; otherwise, FALSE.

https://docs.microsoft.com/en-us/win...irectoryemptya
Return value
Type: BOOL
Returns TRUE if pszPath is an empty directory. Returns FALSE if pszPath is not a directory, or if it contains at least one file other than "." or "..".