Home » excel » excel – VBA Dir Picking Up Ghost File In Directory Named ".." or Documents.xlsx

excel – VBA Dir Picking Up Ghost File In Directory Named ".." or Documents.xlsx

Posted by: admin April 23, 2020 Leave a comment


I’m reasonably famaliar with using the VBA Dir procedure to loop through files in a folder. Usually, I don’t have issues, but on a project I’m working on, the DIR is picking up a file that, as far as I can tell, does not exist. This ultimately causes my code to debug error.

Here is a screenshot of the folder containing the files.
enter image description here

Yet when the code tries to execute the open, it errors (always after successfully doing one file first) and says the issues is because of some file named Documents.XLSX. I rarely use xlsx types, so I don’t know where it’s pulling that name from.

Error VB Shows

Strangely, if I set VBA to debug.print it prints the name as “..” as opposed to the Document.xlsx name.

enter image description here

Does anyone know why this would happen?

I’m certain it has something to do with opening and closing the file because if I remove this action, the code Debug.Prints correctly with the three file names. I considered that maybe closing the file was hanging it, so I included DoEvents after the close, but no change. I even stopped the macro for about a minute after closing the file before running the next line of myFile = Dir and that still didn’t solve it.

Any suggestions on why this is or how further to troubleshoot would be most helpful.

Unfortunately, I don’t even have a workaround. If I set to only execute if myFile <> “..” that works to skip, but for the disappearance and reappearance of “..” is throwing off the “next” option to cause the loop to repeat indefinitely.
Code is pretty standard.

Dim myFile, WB as Workbook
myFile = Dir(dirPath)

Do While (myFile <> "")

'I included this for my own research
Debug.Print myFile

'Opens workbook
'This next line is where the error happens
Set WB = Workbooks.Open(Filename:=dirPath & myFile)

'Macro does stuff

WB.Close savechanges:=False

myFile = Dir


I didn’t think to mention that in a different module, I have a custom function that’s intended to ensure that the user has entered a valid file path in a Cell. I also should mention that my VBA CODE 'do Something is updating cells, and probably causing this custom function recalculate.

This code is….

Public Function isValidPath(FilePATH as String) as Boolean
   If Right(FilePATH,1) <> "\" Then FilePATH = FilePATH & "\"

   If Dir(FilePath, vbDirectory) <> vbNullString then isValidPath = True

End Function

Who wants to earn a free ✔️??

How to&Answers:

A folder will always¹ contain two things. A . represents itself and a .. represents its parent.

If you use Dir with the vbDirectory argument and suffix the path with a backslash as you’ve done then you will return two results; a . and a ... No need for a loop; either it is there or it is not.

If you use Dir with the vbDirectory argument without a backslash suffix then you will return one result; the name of the folder. No need for a loop; either it is there or it is not.

While it is possible to have a file with no extension named what you are looking for as a folder, there cannot be a folder and a file with no extension named the same in the same parent folder. While not fail-safe, it is a reasonable conclusion and if it errors then you should probably be taking a closer look at it in any event.

To summarize, if you look for a folder with or with out a trailing backslash you will receive a non-zero-length-string as a result unless you have a singular very special circumstance.

Your ‘helper’ function code ‘as-is’ should be fine.

Public Function isValidPath(FilePATH as String) as Boolean

   isValidPath = cbool(len(Dir(FilePath, vbDirectory)))

End Function

btw, if you are a fan of walking over errors then this accomplishes the same thing with or without the trailing backslash (i.e. guarantees the folder’s existence to a single sub-folder level).

on error resume next
mkdir FilePATH 
on error goto 0

¹ if I remember my ms-dos 3.3 correctly, even c:\ has a .. but I cannot remember where it points to.