Just an FYI, we just completed a fresh install of 3.3.5.

1. Running on XP, latest patches
2. IIS 5
3. SQL 2000 service pack 4
4. created new site. gave asp.net account full control
5. extracted all files from 3.3.5 install
6. created SQL db and created new user with owner rights
7. edited release.config and changed connection string to the right database, owner and password

Site built with no errors.

Host filemanager will create directories, but will not show the orginal directories that were created during the install.

Admin filemanager will create directories, but will not show the original portal directories that were created during the install.

It appears that all of this is by design. We have examined the behavior and concluded:

1. The host and portal file managers do not display 'DNN system directories' (our term)
2. They will display similar directories (skins, etc) if they were created with a prior version of DNN
3. All other modules that use the standard file manager access will obey these rules as well. For example when editing a text module and clicking on the image link, you will see any 'system-like' directories that were created under a prior version of DNN.  You will NOT see new directories created by 3.3.5.

We haven't tested DNN4 yet, but we assumed this is the same?

Are our observations and subsequent assumptions correct?

Thanks in advance for any clarity on the subject,

Hi ssidle,

You're right.  We did additional testing and the problem is syncronization, not intentional 'hiding' of 'system'directories and files.  Also it did first appear in 3.3.4.

The 3.3.5 upgrade DID NOT fix it.

In addition to not synchronizing the directories (showing them), it sometimes does not remove entries in the file manager for files/directories that have been removed.  We even just used file manager to rename a file (the aspnet.gif that comes with the portal).  The new name showed up, but the old name was NOT removed from the file manager listing.  No amount of syncronization could fix it.

We did load and delete some skins to do additional testing through a module.  Fortuneately, the module can see the new skin directories and files.  Unfortunately, the file manager cannot.  We were able to synch the directories by clicking on the 'skins' folder and selecting the recursive sync. However, the file manager DID NOT remove the old directories from the skins that we uninstalled.

The bottom line, is that we (and I assume a lot of others) are hobbling along.  We had upraded to 3.3.4 because of urging by the core team.  3.3.4 fix a security hole in 3.3.3.

Now that most of our sites have migrated to 3.3.4, we have to manually do a lot more than before.

I can only hope that the Core Team is fervently working on this problem (I checked Gemini, but nothing in the PUBLIC bug tracker).  A problem like this shakes our faith in the platform a bit.  We have been VERY happy with DNN, but a mistake like this is tough to excuse.

Hang in there and good luck!!