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:DatenBüro_GL...
When entering the folder ...
in windows explorer it just points back to its parent folder (G:DatenBü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)
windows filesystems ntfs recursion
add a comment |
On a (German) Server 2008 we found a folder with the name G:DatenBüro_GL...
When entering the folder ...
in windows explorer it just points back to its parent folder (G:DatenBü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)
windows filesystems ntfs recursion
Can your rename the folder by selecting it, pressF2
and then alter its name?
– LPChip
Dec 8 '15 at 11:05
@lpchip No can't rename it, at least while files in the sub folders are in use (closing the files would mean to log off all users from the terminal servers which we would like to avoid)
– marsh-wiggle
Dec 8 '15 at 11:15
If you can't rename because files are in use, you won't be able to do anything with the files really.
– LPChip
Dec 8 '15 at 11:35
What doesdir /al
(not/ah
) show?
– dxiv
Dec 8 '15 at 19:10
@divx "no files found" fordir /al
&dir /ahl
– marsh-wiggle
Dec 9 '15 at 7:23
add a comment |
On a (German) Server 2008 we found a folder with the name G:DatenBüro_GL...
When entering the folder ...
in windows explorer it just points back to its parent folder (G:DatenBü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)
windows filesystems ntfs recursion
On a (German) Server 2008 we found a folder with the name G:DatenBüro_GL...
When entering the folder ...
in windows explorer it just points back to its parent folder (G:DatenBü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)
windows filesystems ntfs recursion
windows filesystems ntfs recursion
asked Dec 8 '15 at 10:52
marsh-wigglemarsh-wiggle
1,81841640
1,81841640
Can your rename the folder by selecting it, pressF2
and then alter its name?
– LPChip
Dec 8 '15 at 11:05
@lpchip No can't rename it, at least while files in the sub folders are in use (closing the files would mean to log off all users from the terminal servers which we would like to avoid)
– marsh-wiggle
Dec 8 '15 at 11:15
If you can't rename because files are in use, you won't be able to do anything with the files really.
– LPChip
Dec 8 '15 at 11:35
What doesdir /al
(not/ah
) show?
– dxiv
Dec 8 '15 at 19:10
@divx "no files found" fordir /al
&dir /ahl
– marsh-wiggle
Dec 9 '15 at 7:23
add a comment |
Can your rename the folder by selecting it, pressF2
and then alter its name?
– LPChip
Dec 8 '15 at 11:05
@lpchip No can't rename it, at least while files in the sub folders are in use (closing the files would mean to log off all users from the terminal servers which we would like to avoid)
– marsh-wiggle
Dec 8 '15 at 11:15
If you can't rename because files are in use, you won't be able to do anything with the files really.
– LPChip
Dec 8 '15 at 11:35
What doesdir /al
(not/ah
) show?
– dxiv
Dec 8 '15 at 19:10
@divx "no files found" fordir /al
&dir /ahl
– marsh-wiggle
Dec 9 '15 at 7:23
Can your rename the folder by selecting it, press
F2
and then alter its name?– LPChip
Dec 8 '15 at 11:05
Can your rename the folder by selecting it, press
F2
and then alter its name?– LPChip
Dec 8 '15 at 11:05
@lpchip No can't rename it, at least while files in the sub folders are in use (closing the files would mean to log off all users from the terminal servers which we would like to avoid)
– marsh-wiggle
Dec 8 '15 at 11:15
@lpchip No can't rename it, at least while files in the sub folders are in use (closing the files would mean to log off all users from the terminal servers which we would like to avoid)
– marsh-wiggle
Dec 8 '15 at 11:15
If you can't rename because files are in use, you won't be able to do anything with the files really.
– LPChip
Dec 8 '15 at 11:35
If you can't rename because files are in use, you won't be able to do anything with the files really.
– LPChip
Dec 8 '15 at 11:35
What does
dir /al
(not /ah
) show?– dxiv
Dec 8 '15 at 19:10
What does
dir /al
(not /ah
) show?– dxiv
Dec 8 '15 at 19:10
@divx "no files found" for
dir /al
& dir /ahl
– marsh-wiggle
Dec 9 '15 at 7:23
@divx "no files found" for
dir /al
& dir /ahl
– marsh-wiggle
Dec 9 '15 at 7:23
add a comment |
4 Answers
4
active
oldest
votes
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.
Thanks. I hope we will get a slot for maintance this weekend. I will give you a feedback
– marsh-wiggle
Dec 8 '15 at 15:18
The chksdsk didn't fix the problem. We will move the data to a new folder in the next longer maintance time Thanks for theits own ancestor
hint. +1
– marsh-wiggle
Dec 14 '15 at 16:04
add a comment |
The reason you see ... behaving like this is due to a win32 compatability layer thing resulting in ... always goes to grandparent of the current folder (it emulates NetWare behavior but accidentally got applied to local filesystems).
You cannot see inside this folder with cmd.exe or Windows Explorer. If you can get interix working (this OS is too old for LUFS) you can descend that way. Otherwise you're going to have to write a lot of code using FILE_FLAG_POSIX_SEMANTICS to get that thing open and see what is really inside it.
add a comment |
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.
add a comment |
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.
If your...
directory was empty, you didn’t have the same problem as the one discussed here.
– Scott
Jan 25 at 8:39
I don't see it so. Entering the "..." folder just "throws" you back to the parent directory. So this looked like there are subfolders (We had the same symptoms). You did not see the real content without "force". But you can adept this solution:cd "C:..."
and work in there had a good chance to work. Alsoren "C:,,," "C:xxx"
had a good chance to work.
– Ralph Erdt
Jan 25 at 9:26
(1) You say “… this looked like there are subfolders (We had the same symptoms).” But you also said “So I tried these: —dir "C:..."
— And an empty directory was shown.” It seems to me that you are contradicting yourself. (2) When you saidren "C:,,," "C:xxx"
, did you meanren "C:..." "C:xxx"
?
– Scott
Jan 25 at 18:53
(1) I've extended my answer with examples. Please feel free to comment. (2) You are right, sorry for the typo. (3) I've tested the "cd" and "ren" suggestions. They did not work. :(
– Ralph Erdt
Jan 28 at 7:05
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "3"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1010544%2fhow-to-get-rid-of-folder-containing-just-three-dots-pointing-to-its-paren%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
4 Answers
4
active
oldest
votes
4 Answers
4
active
oldest
votes
active
oldest
votes
active
oldest
votes
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.
Thanks. I hope we will get a slot for maintance this weekend. I will give you a feedback
– marsh-wiggle
Dec 8 '15 at 15:18
The chksdsk didn't fix the problem. We will move the data to a new folder in the next longer maintance time Thanks for theits own ancestor
hint. +1
– marsh-wiggle
Dec 14 '15 at 16:04
add a comment |
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.
Thanks. I hope we will get a slot for maintance this weekend. I will give you a feedback
– marsh-wiggle
Dec 8 '15 at 15:18
The chksdsk didn't fix the problem. We will move the data to a new folder in the next longer maintance time Thanks for theits own ancestor
hint. +1
– marsh-wiggle
Dec 14 '15 at 16:04
add a comment |
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.
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.
answered Dec 8 '15 at 15:01
Ben NBen N
29.8k1398145
29.8k1398145
Thanks. I hope we will get a slot for maintance this weekend. I will give you a feedback
– marsh-wiggle
Dec 8 '15 at 15:18
The chksdsk didn't fix the problem. We will move the data to a new folder in the next longer maintance time Thanks for theits own ancestor
hint. +1
– marsh-wiggle
Dec 14 '15 at 16:04
add a comment |
Thanks. I hope we will get a slot for maintance this weekend. I will give you a feedback
– marsh-wiggle
Dec 8 '15 at 15:18
The chksdsk didn't fix the problem. We will move the data to a new folder in the next longer maintance time Thanks for theits own ancestor
hint. +1
– marsh-wiggle
Dec 14 '15 at 16:04
Thanks. I hope we will get a slot for maintance this weekend. I will give you a feedback
– marsh-wiggle
Dec 8 '15 at 15:18
Thanks. I hope we will get a slot for maintance this weekend. I will give you a feedback
– marsh-wiggle
Dec 8 '15 at 15:18
The chksdsk didn't fix the problem. We will move the data to a new folder in the next longer maintance time Thanks for the
its own ancestor
hint. +1– marsh-wiggle
Dec 14 '15 at 16:04
The chksdsk didn't fix the problem. We will move the data to a new folder in the next longer maintance time Thanks for the
its own ancestor
hint. +1– marsh-wiggle
Dec 14 '15 at 16:04
add a comment |
The reason you see ... behaving like this is due to a win32 compatability layer thing resulting in ... always goes to grandparent of the current folder (it emulates NetWare behavior but accidentally got applied to local filesystems).
You cannot see inside this folder with cmd.exe or Windows Explorer. If you can get interix working (this OS is too old for LUFS) you can descend that way. Otherwise you're going to have to write a lot of code using FILE_FLAG_POSIX_SEMANTICS to get that thing open and see what is really inside it.
add a comment |
The reason you see ... behaving like this is due to a win32 compatability layer thing resulting in ... always goes to grandparent of the current folder (it emulates NetWare behavior but accidentally got applied to local filesystems).
You cannot see inside this folder with cmd.exe or Windows Explorer. If you can get interix working (this OS is too old for LUFS) you can descend that way. Otherwise you're going to have to write a lot of code using FILE_FLAG_POSIX_SEMANTICS to get that thing open and see what is really inside it.
add a comment |
The reason you see ... behaving like this is due to a win32 compatability layer thing resulting in ... always goes to grandparent of the current folder (it emulates NetWare behavior but accidentally got applied to local filesystems).
You cannot see inside this folder with cmd.exe or Windows Explorer. If you can get interix working (this OS is too old for LUFS) you can descend that way. Otherwise you're going to have to write a lot of code using FILE_FLAG_POSIX_SEMANTICS to get that thing open and see what is really inside it.
The reason you see ... behaving like this is due to a win32 compatability layer thing resulting in ... always goes to grandparent of the current folder (it emulates NetWare behavior but accidentally got applied to local filesystems).
You cannot see inside this folder with cmd.exe or Windows Explorer. If you can get interix working (this OS is too old for LUFS) you can descend that way. Otherwise you're going to have to write a lot of code using FILE_FLAG_POSIX_SEMANTICS to get that thing open and see what is really inside it.
answered Apr 16 '18 at 19:12
JoshuaJoshua
530315
530315
add a comment |
add a comment |
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.
add a comment |
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.
add a comment |
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.
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.
edited May 13 '18 at 10:08
Kamil Maciorowski
28.1k156185
28.1k156185
answered May 13 '18 at 9:34
Didier HDidier H
11
11
add a comment |
add a comment |
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.
If your...
directory was empty, you didn’t have the same problem as the one discussed here.
– Scott
Jan 25 at 8:39
I don't see it so. Entering the "..." folder just "throws" you back to the parent directory. So this looked like there are subfolders (We had the same symptoms). You did not see the real content without "force". But you can adept this solution:cd "C:..."
and work in there had a good chance to work. Alsoren "C:,,," "C:xxx"
had a good chance to work.
– Ralph Erdt
Jan 25 at 9:26
(1) You say “… this looked like there are subfolders (We had the same symptoms).” But you also said “So I tried these: —dir "C:..."
— And an empty directory was shown.” It seems to me that you are contradicting yourself. (2) When you saidren "C:,,," "C:xxx"
, did you meanren "C:..." "C:xxx"
?
– Scott
Jan 25 at 18:53
(1) I've extended my answer with examples. Please feel free to comment. (2) You are right, sorry for the typo. (3) I've tested the "cd" and "ren" suggestions. They did not work. :(
– Ralph Erdt
Jan 28 at 7:05
add a comment |
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.
If your...
directory was empty, you didn’t have the same problem as the one discussed here.
– Scott
Jan 25 at 8:39
I don't see it so. Entering the "..." folder just "throws" you back to the parent directory. So this looked like there are subfolders (We had the same symptoms). You did not see the real content without "force". But you can adept this solution:cd "C:..."
and work in there had a good chance to work. Alsoren "C:,,," "C:xxx"
had a good chance to work.
– Ralph Erdt
Jan 25 at 9:26
(1) You say “… this looked like there are subfolders (We had the same symptoms).” But you also said “So I tried these: —dir "C:..."
— And an empty directory was shown.” It seems to me that you are contradicting yourself. (2) When you saidren "C:,,," "C:xxx"
, did you meanren "C:..." "C:xxx"
?
– Scott
Jan 25 at 18:53
(1) I've extended my answer with examples. Please feel free to comment. (2) You are right, sorry for the typo. (3) I've tested the "cd" and "ren" suggestions. They did not work. :(
– Ralph Erdt
Jan 28 at 7:05
add a comment |
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.
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.
edited Jan 28 at 7:03
answered Jan 25 at 8:09
Ralph ErdtRalph Erdt
114
114
If your...
directory was empty, you didn’t have the same problem as the one discussed here.
– Scott
Jan 25 at 8:39
I don't see it so. Entering the "..." folder just "throws" you back to the parent directory. So this looked like there are subfolders (We had the same symptoms). You did not see the real content without "force". But you can adept this solution:cd "C:..."
and work in there had a good chance to work. Alsoren "C:,,," "C:xxx"
had a good chance to work.
– Ralph Erdt
Jan 25 at 9:26
(1) You say “… this looked like there are subfolders (We had the same symptoms).” But you also said “So I tried these: —dir "C:..."
— And an empty directory was shown.” It seems to me that you are contradicting yourself. (2) When you saidren "C:,,," "C:xxx"
, did you meanren "C:..." "C:xxx"
?
– Scott
Jan 25 at 18:53
(1) I've extended my answer with examples. Please feel free to comment. (2) You are right, sorry for the typo. (3) I've tested the "cd" and "ren" suggestions. They did not work. :(
– Ralph Erdt
Jan 28 at 7:05
add a comment |
If your...
directory was empty, you didn’t have the same problem as the one discussed here.
– Scott
Jan 25 at 8:39
I don't see it so. Entering the "..." folder just "throws" you back to the parent directory. So this looked like there are subfolders (We had the same symptoms). You did not see the real content without "force". But you can adept this solution:cd "C:..."
and work in there had a good chance to work. Alsoren "C:,,," "C:xxx"
had a good chance to work.
– Ralph Erdt
Jan 25 at 9:26
(1) You say “… this looked like there are subfolders (We had the same symptoms).” But you also said “So I tried these: —dir "C:..."
— And an empty directory was shown.” It seems to me that you are contradicting yourself. (2) When you saidren "C:,,," "C:xxx"
, did you meanren "C:..." "C:xxx"
?
– Scott
Jan 25 at 18:53
(1) I've extended my answer with examples. Please feel free to comment. (2) You are right, sorry for the typo. (3) I've tested the "cd" and "ren" suggestions. They did not work. :(
– Ralph Erdt
Jan 28 at 7:05
If your
...
directory was empty, you didn’t have the same problem as the one discussed here.– Scott
Jan 25 at 8:39
If your
...
directory was empty, you didn’t have the same problem as the one discussed here.– Scott
Jan 25 at 8:39
I don't see it so. Entering the "..." folder just "throws" you back to the parent directory. So this looked like there are subfolders (We had the same symptoms). You did not see the real content without "force". But you can adept this solution:
cd "C:..."
and work in there had a good chance to work. Also ren "C:,,," "C:xxx"
had a good chance to work.– Ralph Erdt
Jan 25 at 9:26
I don't see it so. Entering the "..." folder just "throws" you back to the parent directory. So this looked like there are subfolders (We had the same symptoms). You did not see the real content without "force". But you can adept this solution:
cd "C:..."
and work in there had a good chance to work. Also ren "C:,,," "C:xxx"
had a good chance to work.– Ralph Erdt
Jan 25 at 9:26
(1) You say “… this looked like there are subfolders (We had the same symptoms).” But you also said “So I tried these: —
dir "C:..."
— And an empty directory was shown.” It seems to me that you are contradicting yourself. (2) When you said ren "C:,,," "C:xxx"
, did you mean ren "C:..." "C:xxx"
?– Scott
Jan 25 at 18:53
(1) You say “… this looked like there are subfolders (We had the same symptoms).” But you also said “So I tried these: —
dir "C:..."
— And an empty directory was shown.” It seems to me that you are contradicting yourself. (2) When you said ren "C:,,," "C:xxx"
, did you mean ren "C:..." "C:xxx"
?– Scott
Jan 25 at 18:53
(1) I've extended my answer with examples. Please feel free to comment. (2) You are right, sorry for the typo. (3) I've tested the "cd" and "ren" suggestions. They did not work. :(
– Ralph Erdt
Jan 28 at 7:05
(1) I've extended my answer with examples. Please feel free to comment. (2) You are right, sorry for the typo. (3) I've tested the "cd" and "ren" suggestions. They did not work. :(
– Ralph Erdt
Jan 28 at 7:05
add a comment |
Thanks for contributing an answer to Super User!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1010544%2fhow-to-get-rid-of-folder-containing-just-three-dots-pointing-to-its-paren%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Can your rename the folder by selecting it, press
F2
and then alter its name?– LPChip
Dec 8 '15 at 11:05
@lpchip No can't rename it, at least while files in the sub folders are in use (closing the files would mean to log off all users from the terminal servers which we would like to avoid)
– marsh-wiggle
Dec 8 '15 at 11:15
If you can't rename because files are in use, you won't be able to do anything with the files really.
– LPChip
Dec 8 '15 at 11:35
What does
dir /al
(not/ah
) show?– dxiv
Dec 8 '15 at 19:10
@divx "no files found" for
dir /al
&dir /ahl
– marsh-wiggle
Dec 9 '15 at 7:23