How to get rid of folder containing just three dots [...] (pointing to its parent folder)

On a (German) Server 2008 we found a folder with the name G:\Daten\Büro_GL\...

When entering the folder ... in windows explorer it just points back to its parent folder (G:\Daten\Büro_GL).

The folder can't be deleted, because it would delete also every subfolder. Also denying List folder content only for This folder doesn't work. The deny then is applied to the parent folder, too.

The folder [...] is a folder and not a symbolic link:

We would like to avoid moving the content of the folder, to not to interrupt the workflow on the productive system.

(I'm also keen to know how such a folder could be created)

SOLVED

I just accidentally created a folder with 3 dots. ....

I just tried to build my angular application like this:

ng build --outputpath=.../public

A regular windows command wouldn't delete it.

I just realized that, if ng cli command can create the folder, it can delete it too.

I just made an intentional error in my code and executed the same command.

Boom - the folder was gone.

This might help someone.

More info for non angular users

1. install npm and go to the path where you have the ... file

2. Then npm install -g @angular/cli

3. ng new mockproject. This will create the mockproject folder in your path.

4. Edit the package.json and add to the "build" line --outputpath=.../public

5. Copy everything in the mockproject folder to where you have the ...

6. Edit app.module.ts and add some garbage characters there (making an error in the project)

7. npm run build. This will give you an error.

Now you don't have the ... folder.

Background: I think the ng uses posix - so, it can create these system-like files. I guess any posix tool like sygwin can remove these files.

This can only happen if the NTFS data structures get confused, causing a folder to be its own ancestor. It's possible that a driver is at fault. The drive itself could be failing, or the corruption might just be from a cosmic ray.

One job of the chkdsk utility is to clean up folders that literally contain themselves - cycles within the folder structure. (Source.) Since chkdsk /? states that /C skips the checking for cycles, it can be inferred that the normal behavior is to repair them.

Run chkdsk /f D: in an elevated command prompt to fix the problem, along with any other inconsistencies. The volume will have to go offline during the repair. If it is the boot volume, you'll need to reboot after scheduling the disk check.

Solved this by my co worker, sadly I closed the cmd before realizing it.. I'll write the things I remember..

My CoWorker got the "..." directory in root of C: So I tried these:

dir "C:\...\"

And a empty directory was shown. So a

rmdir "C:\...\"

deletes the directory

A bit Background:

Windows File-IO APIs call at first a file name check. And a "..." was interpenetrated as ".." - so, go a director up. Try thyping in Exporer "C:\Windows..\ProgramData". (FYI: In the API is mentioned: If the filename beginns with "\?\", the check is disabled and Such directories can be accessed: Because it turns off automatic expansion of the path string, the "\\?\" prefix also allows the use of ".." and "." in the path names, which can be useful if you are attempting to perform operations on a file with these otherwise reserved relative path specifiers as part of the fully qualified path. But this is information for a programmer.)

Edit:

Because of the discussion "Fit this answer to the question?":

I've tested it. Created a directory. This is how it looks like in Explorer:

And this is what you see with "dir":

So: The directory is empty, but Explorer is showing "wrong" information. This is not a conflict considering how the Windows API works: The File API tries to do interpretation of the file / directory name. So move a directory up, if there is a "..", etc. That is what you see in the explorer view. In the cmd I tried to find a string forcing the Windows API no doing a interpretation.

On how a ... folder could be created: I accidentally created one using 7-zip (18.05) by defining an archive name ...\filename.7z.

Fortunately, the directory could be renamed with 7-zip and subsequently deleted.