Return to Answer

Win32 doesn't let you create files or folders with names ending in . – all dots are stripped from the end. Trying to create test. makes test appear instead. (This is for compatibility with 8.3 names in old DOS/Win9x era software.)

As a result, whenever you try to access a folder named ...., its name gets reduced to the empty string, and you're back to the folder you were in before.

The NT kernel, however, does allow such names. There are various mechanisms which bypass filename limitations imposed by Win32 APIs – for example, WSL (Windows Subsystem for Linux) doesn't run on top of Win32 and is unaffected by it. There is also the \\?\ bypass method, a deliberate "backdoor" left in for programs which know what they're doing. Even though you cannot create C:\Example\....\, you can create \\?\C:\Example\....\ just fine.

Likewise you can delete such directories with rmdir \\?\C:\path\... from Cmd (I haven't tested with PowerShell yet).

Various file managers, archivers, etc. might use the \\?\ method in order to be able to use longer path names than usual – and by doing so, they're also unaffected by the compatibility code within Win32; they bypass dot stripping, as well as translation of magic filenames like CON or NUL.

So it could be that one of your programs 1) always uses \\?\ to access files, and 2) accidentally tried to create a folder named .... – but it's not really possible to know for sure after the fact.

Win32 doesn't let you create files or folders with names ending in . – all dots are stripped from the end. Trying to create test. makes test appear instead. (This is for compatibility with 8.3 names in old DOS/Win9x era software.)

As a result, whenever you try to access a folder named ...., its name gets reduced to the empty string, and you're back to the folder you were in before.

The NT kernel, however, does allow such names. There are various mechanisms which bypass filename limitations imposed by Win32 APIs – for example, WSL (Windows Subsystem for Linux) doesn't run on top of Win32 and is unaffected by it. There is also the \\?\ bypass method, a deliberate "backdoor" left in for programs which know what they're doing. Even though you cannot create C:\Example\....\, you can create \\?\C:\Example\....\ just fine.

Likewise you can delete such directories with rmdir \\?\C:\path\... from Cmd (I haven't tested with PowerShell yet).

Various file managers, archivers, etc. might use the \\?\ method in order to be able to use longer path names than usual – and by doing so, they're also unaffected by the compatibility code within Win32; they bypass dot stripping, as well as translation of magic filenames like CON or NUL.

So it could be that one of your programs:

1. always uses \\?\ to access files,
2. accidentally tried to create a folder named .... – but it's not really possible to know for sure after the fact.

Win32 doesn't let you create files or folders with names ending in . – all dots are stripped from the end. Trying to create test. makes test appear instead. (This is for compatibility with 8.3 names in old DOS/Win9x era software.)

As a result, whenever you try to access a folder named ...., its name gets reduced to the empty string, and you're back to the folder you were in before.

The NT kernel, however, does allow such names. There are various mechanisms which bypass filename limitations imposed by Win32 APIs – for example, WSL (Windows Subsystem for Linux) doesn't run on top of Win32 and is unaffected by it. There is also the \\?\ bypass method, a deliberate "backdoor" left in for programs which know what they're doing. Even though you cannot create C:\Example\....\, you can create \\?\C:\Example\....\ just fine.

Various file managers, archivers, etc. might use the \\?\ method in order to be able to use longer path names than usual – and by doing so, they're also unaffected by the compatibility code within Win32; they bypass dot stripping, as well as translation of magic filenames like CON or NUL.

So it could be that one of your programs 1) always uses \\?\ to access files, and 2) accidentally tried to create a folder named .... – but it's not really possible to know for sure after the fact.

Win32 doesn't let you create files or folders with names ending in . – all dots are stripped from the end. Trying to create test. makes test appear instead. (This is for compatibility with 8.3 names in old DOS/Win9x era software.)

As a result, whenever you try to access a folder named ...., its name gets reduced to the empty string, and you're back to the folder you were in before.

The NT kernel, however, does allow such names. There are various mechanisms which bypass filename limitations imposed by Win32 APIs – for example, WSL (Windows Subsystem for Linux) doesn't run on top of Win32 and is unaffected by it. There is also the \\?\ bypass method, a deliberate "backdoor" left in for programs which know what they're doing. Even though you cannot create C:\Example\....\, you can create \\?\C:\Example\....\ just fine.

Likewise you can delete such directories with rmdir \\?\C:\path\... from Cmd (I haven't tested with PowerShell yet).

Various file managers, archivers, etc. might use the \\?\ method in order to be able to use longer path names than usual – and by doing so, they're also unaffected by the compatibility code within Win32; they bypass dot stripping, as well as translation of magic filenames like CON or NUL.

So it could be that one of your programs 1) always uses \\?\ to access files, and 2) accidentally tried to create a folder named .... – but it's not really possible to know for sure after the fact.

Win32 doesn't let you create files or folders with names ending in . – all dots are stripped from the end. Trying to create test. makes test appear instead. (This is for compatibility with 8.3 names in old DOS/Win9x era software.)

As a result, whenever you try to access a folder named ...., its name gets reduced to the empty string, and you're back to the folder you were in before.

The NT kernel, however, does allow such names. There are various mechanisms which bypass filename limitations imposed by Win32 APIs – for example, WSL (Windows Subsystem for Linux) doesn't run on top of Win32 and is unaffected by it. There is also the \\?\ bypass method, a deliberate "backdoor" left in for programs which know what they're doing. Even though you cannot create C:\Example\....\, you can create \\?\C:\Example\....\ just fine.

Various file managers, archivers, etc. might use the \\?\ method in order to be able to use longer path names than usual – and by doing so, they're also unaffected by the compatibility code within Win32; they bypass dot stripping, as well as translation of magic filenames like CON or NUL.

So it could be that one of your programs 1) always uses \\?\ to access files, and 2) accidentally tried to create a folder named .... – but it's not really possible to know for sure after the fact.

Win32 doesn't let you create files or folders with names ending in . – all dots are stripped from the end. Trying to create test. makes test appear instead. (This is for compatibility with 8.3 names in old DOS/Win9x era software.)

As a result, whenever you try to access a folder named ...., its name gets reduced to the empty string, and you're back to the folder you were in before.

The NT kernel, however, does allow such names. There are various mechanisms which bypass filename limitations imposed by Win32 APIs – for example, WSL (Windows Subsystem for Linux) doesn't run on top of Win32 and is unaffected by it. There is also the \\?\ bypass method, a deliberate "backdoor" left in for programs which know what they're doing. Even though you cannot create C:\Example\....\, you can create \\?\C:\Example\....\ just fine.

Various file managers, archivers, etc. might use the \\?\ method in order to be able to use longer path names than usual – and by doing so, they're also unaffected by the compatibility code within Win32; they bypass dot stripping, as well as translation of magic filenames like CON or NUL.

So it could be that one of your programs 1) always uses \\?\ to access files, and 2) accidentally tried to create a folder named .... – but it's not really possible to know for sure after the fact.