Every DNN developer I've been in communication with has expressed frustration with the file manager in DNN 4.
The main issue I'm having is that the File Manager no longer synchs correctly if you delete files by other means (such as FTP or manually on the server).
I've spent hours/days searching the "bug" and have come to the conclusion that this is the behavior the core team intended. This is further backed up by the note in the DNN 4 Book (page 125) warning not to delete files by outside means.
There's no logic present in the file synch routine to accomplish the removal of non-existent files.
This choice is more than a stumbling block to end users. It's a true show stopper and one that the core team will eventually have to change their position on. Sticking to this will cause countless users untold hours of frustration. It's an unrealistic assumption/expectation to assert that users cannot delete files any other way than the portal file manager.
The reality "on the ground" (to borrow some recent terms) is that my users interact with their portals frequently by FTP. It's simply not practical to be uploading large media files (in excess of 20 meg) via HTTP. While they're FTP'd in they may delete the old stuff as well.
When viewed in this light, at times the DNN file manager is just a necessary accessory to keep the portal in sync. Now that doesn't even work.
In addition to this, there are plenty of Javascript problems when using Firefox or I.E. 7. While I realize I.E. 7 is still "Beta" and the immediate argument is that it's not supported, you can't say the same for Firefox - it's just too widely accepted. We can no longer live in an IE only world.
Reports of "bugs" to the DNN Bug Tracker regarding this are simply closed.
I've been with DNN since version 1 and doing commercial work since version 2. I've practically married my business to this framework. I have a huge investment in DNN in both time and real dollars. I'm no "johnny-come-lately" and I have the utmost respect and gratitude for the core team and their efforts.
Despite all this, I can see no workaround to this omission. I'm forced to hold existing clients to previous versions (3.2 and below) that don't have this issue. And I may have to rebuild two current projects in previous versions or go looking for a new platform.