A red message that stops the whole page from loading; a full page, but a message that looks like it came from the server; a red box with red text that we made: All of these are bugs you can see, so report them here. kthxbai
Even better, check to see if the database actually already has a duplicate entry for any given file name ... and see if there is anything funky in the files table then the attachments table. Or it might be the links table. In other words is the database funky before ever getting to FM in a popup is the idea.
EdB wrote:The file manager in popup is the exact same file as file manager in a regular.
That makes this all the more strange since the file manager in the regular view does not do this., only when I go to the write form and click on files.
I noticed that it actually reads in the thumbnail, and displays the properties of the file that it is complaining about. I have looked in the database and saw no problem. Maybe it is actually the next file, and not the one it is displaying in the error message.
Since it did not do it with the v0.0.0 files folder, it made me believe that it has to do with something about the current trunk files that is different.
I definitely need to investigate this before the next version is released just to make sure that there is not a problem with the current trunk.
EdB wrote:Correct me if I'm wrong, but the only time this happens is when you import an evo database into a QP installation?
Can you do the migrator then do an upgrade and see if the problem persists? Or have you done that and already seen the problem?
I did the second thing you stated above and the problem continued to exist
However, I tried your file deletion thing even though I could not see any duplicate entries in the files database table. I first deleted the file mentioned in the SQL error by simply removing it by ftp. Then it jumped to the next file similarly named with the same error. I ftp the file back in place and got the SQL error for that file. So I used the regular file manager to remove all three files that had similar names. I checked the server and they were removed from the server. However, I go to my control panel and using phpMyAdmin, I open the database and there are still two entries for the first two files, iris_1.jpg and iris_2.jpg. the third one is gone. So that lead me to believe that there was duplicate entries even though phpMyAdmin did not show them. I searched the database before and only found one entry; maybe this is a glitch with phpMyAdmin that it simply skipped showing the duplicate entry, I don't know. I think I will open the SQL dump I made while testing things to see if it shows two entries since that is more or less a text file.
If it had done the same in both the regular view of file manager and the pop-up view of the file manager, and did the same in the old version of files from v0.0.0, I would not have gone off in a direction that was just wasting time.
Why didn't the old version of the files kick out the same error? Why didn't the regular view of file manager kick out the same error?
This was probably just a fluke of doing the migration, opening a remote connection to the old database to grab data and insert it into the new database. If it was not for the things I mentioned above, I wouldn't have thought that something else was at play.
I am guessing to fix the 403 errors on three different files from the ones above means doing the same thing. I really don't understand why they are reporting 403 when they are in the same media folder with the same permission settings.
I still have the old installation of my blog in place, the database has not been touched and is still on the SQL server. I think I will do another migration to see what happens. Who knows, maybe this was a duplicate entry that existed on the old and some changes we made in the files are not as forgiving as the old for such things. I will do the migration to v0, and then upgrade to the latest trunk and see if the error returns.