Hello,

I'm worried about some bugs on the File Manager. Some were introduced on DNN 6.1.0, others are there since 6.0.0, and one exists since DNN 4 or even before that.

I've posted them (some, month ago) at http://support.dotnetnuke.com, and they are not even read or 'verified'. 

The worst ones are:  

This one is new to  6.1.0:

 http://support.dotnetnuke.com/issue/ViewIssue.aspx?id=18830&PROJID=2 

These are present since  6.0.0:

http://support.dotnetnuke.com/issue/ViewIssue.aspx?id=17836&PROJID=2 

http://support.dotnetnuke.com/issue/ViewIssue.aspx?id=17696&PROJID=2

http://support.dotnetnuke.com/issue/ViewIssue.aspx?id=17691&PROJID=2 

DNN-18830 makes the File Manager unusable (very slow), and it is very easy to fix.

DNN-17836 makes slow and inefficient all sync operations, and it is very easy to fix.

DNN-17696 confuses people, because they do not found files that are there (because the permissions are wrong)

DNN-17691 is there since DNN4 (or even before), and it affects any file (which is not an image) that is updated. 

For example, if you have a ZIP or PDF already uploaded, and you update it. Its size (in the Files table) is never updated. Therefore downloading it with many modules turns into a corrupted download. 

This is also very easy to fix.

Complete list:

• DNN-17690
• DNN-17691
• DNN-17696
• DNN-17836
• DNN-18498
• DNN-18640
• DNN-18641
• DNN-18829
• DNN-18830

My question is, will the ugliest bugs in this list be fixed soon? Or at least validated/recognized as bugs, and have a ETA to be solved? 

Or should I create a custom File Manager module to overcome them? This sounds like a waste of time, but, if there is no choice...

Thanks,

Horacio.-

Actually, some of the issues includes code references...
Anyway, where can I get the latest source code to work with? (the public 6.1.1 code should not be it)

I would argue that anything that makes the file manager unusable isn't exactly a low priority fix. File manager is an essential tool. What some may have missed from the posts is that the quick workaround is to turn off auto-sync. While this may present some concurrency issues it does restore file manager instantly to usability in 6.x . While I applaud the idea of an "easy" fix, I suspect it's a little more complex. The meta data is needed only from certain files, and the best fix would be to create a list of valid extensions to load the file data from, and then to design a caching method so it's not reloaded unless the file is changed. That presents all sorts of interesting challenges none of which fall into the category of "easy" if I know my coding.... :)