Windows – Folder doesn’t show up in explorer, cmd, and python even though I can access it, how can I fix this

filesystemsnetwork-sharentfswindowswindows-xp

I am accessing another computer on the network using a mapped network drive. The path looks like \\192.168.0.100\d$ which is mapped to my computer's "m" drive. I can access, view, create, delete, move, etc folders on this drive. However, some folders don't show up in windows explorer, even tho I can access them.

Example:

Lets say that M:\stuff\more_stuff is a directory.

What I can't do:

  • When windows explorer is pointed at M:\stuff I can't see more_stuff
  • In cmd prompt pointed at M:\stuff "dir" doesn't find more_stuff
  • In cmd prompt pointed at M:\stuff "dir /a" doens't find more_stuff
  • In python, os.listdir at M:\stuff doens't find more_stuff

What I can do:

  • Typing M:\stuff\more_stuff into the address bar lets me access the folder like normal.

Because there is no indication that this folder even exists, there could be more like them. I have no way of knowing how many folders are magically hidden on this mapped drive.

What are some steps I can do to figure out why this folder is hidden? (With the end goal of making it no longer hidden).

More info:

Accessing the drive through the map M:\stuff and the unc path **\192.168.0.100\d$** result in the same behavior.

Using windows search fails to see the folder.

In cmd prompt pointed at M:\stuff the command > del more_stuff does work.

Accessing the same drive from another machine with the same user account will show the folder correctly (at least in some cases).

Some users say they never experience this problem, and at least two users do experience this problem.

All of the users involved are local admins on the PC hosting the drive.

Restarting the affected machine doesn't fix the issue.

User1 and User2 are having problems seeing folders on this drive. So far any folder that User1 can't see neither can User2.

net use \192.168.0.100\d$ /delete doesn't help

Perhaps the Most Revealing Information So Far

User1 uses MachineA and has this problem. User3 has never had this problem. When User3 logs into MachineA, User3 experiences the problem.

Possibly Related

When accessing the drive like this \192.168.0.100\d$ the share runs as expected (minus the missing folder problem, but everything else is fine). While accessing the drive like this \192.168.0.100\d (no $, because d$ is shared as d) the share is incredibly slow. Explorer windows accessing the share hang for 10-30 seconds every time you change directories.

Playing With Shares

Okay now it gets weird. I shared \192.168.0.100\d$\stuff as e$. When I access \192.168.0.100\d$ or \192.168.0.100\d (notice no $) the more_stuff folder is missing. When I access \192.168.0.100\e$ the more_stuff folder is visible! So I mapped \192.168.0.100\e$ as a new drive, and more_stuff is missing again!

Share Properties

I accessed the share properties from Start > Right-click on "Computer" > Select "Manage" > Shared Folders > Shares > and found the following.

There are a handful of shares on this machine. One of those shares is "d$" mapped to "d:\" and when right clicked it says "shared for administrative purposes. Another one of the shares listed is "d" mapped to "d:\". When right clicked it brings up the normal properties. Is this a problem? Having two shares point to the same drive, one is "d$" and one is "d"?

Best Answer

That's some strange_stuff.

Perhaps my imagination is failing me, but I can't think of anything that can hide a folder from a 'dir /a' command while leaving you with access to the contents of that folder.

First of all, try restarting the host and the client if you can. If that doesn't work...

You might have run in to some strange/corrupt permissions. Try accessing the permission of folder in question (M:\stuff\more_stuff) and see if they make sense. To do this, access the folder from Windows Explorer as you described and right click somewhere in the 'white' (not on a file), select properties / security. Make sure the permissions appear as expected.

If the permissions are somehow not what you expected, try resetting them by accessing the "Advanced" button under the Security tab and enabling the "Include inheritable permissions from this object's parent" option.

Should the behavior you're experiencing be related to permissions, you can reset all of the permissions for objects in the M:\stuff folder by modifying the permissions of M:\stuff and selecting the "Replace all child object permissions with inheritable permissions from this object" option. Careful, you'll lose any explicit permissions you've configured if you do this.

Two more thoughts:

  1. Run a disk check with the fix & recovery option selected on the host
  2. Check the host for mysterious 3rd party tools and viruses (just in case)

Best of luck!