We've just upgraded 2.0.13 to 2.0.14 and also PHP 5.6 to 7.2. All appears to be working fine except that all the members photos have dissappeared. Adding a new photo works fine, but before we have to ask all our members to update their profile with a new photo is there a simple explanation for this?
The files appear to be there in the attachments directory and there is nothing obvious amiss with the smf_attachments table in the database.
Other attachments, added by members to their posts, download fine, it's just the members' photos that have gone.
Any clues? Thanks.
well, I'd finish the upgrade path first... 2.0.14 does not support php 7.2 and there are several functional and security updates up to 2.0.17
Think I saw this once before, will have to think about. If you right click on missing image icon does it give you correct path/filename? Have you tried uninstalling .14 to see if avatars reappear? And do as Kindred suggested, finish updates.
I've now upgraded to 2.0.17, but the problem remains. Also it appears that attachments that are images are corrupt, as well as avatars. Most of our attachments are documents, mostly PDF, and they seem fine.
Lainaus käyttäjältä: DavidRMason - huhtikuu 18, 2020, 07:38:32 AP
I've now upgraded to 2.0.17, but the problem remains. Also it appears that attachments that are images are corrupt, as well as avatars. Most of our attachments are documents, mostly PDF, and they seem fine.
Do they show when browsing in Firefox?
in the process of changing php versions were the files moved to a new server? it is possible the attachments were downloaded were not in binary form and got corrupted. the only way to fix that is to get access to the old files and download/upload them again in binary.
I had always believed that my FTP program FileZilla makes an exact binary copy of everything but this turns out not to be the case. It has 3 settings - Auto, ASCII and Binary and the default is Auto. I have never experienced problems before but this is probably because the Auto setting uses the extension to decide and in this case the attachments have no extension so it defaults incorrectly. Unfortunately this means ALL my backups have the same problem and there is no way to recover any documents for which ASCII copy failed other than asking the original poster to reinstate them. A hard learning experience! Needless to say all my backups are now binary.
Argh... the Filezilla trap. Sorry for your situation.
But not keeping ones eyes on the job at hand is often the real cause of problems. For the attachments, not using binary in Filezilla will change the filesize, a very clear warning. With any ftp transfer in any program, always check and all will be well.
Ideally don't use FTP, use SFTP if available.
This should be solved in 2.1, since as the FileZilla team decided that "files without extensions are presumed to be text" is not a bug, we have attachment file names with an extension in 2.1...
FileZilla has a second setting that causes this problem, it's quite buried and if you don't know it's there will cause 2.0 attachments to transfer as ASCII if transfer type is set to Auto -
Edit -> Settings -> Transfers -> File Types -> Treat files without extensions as ASCII file
That's not a 'second setting', that's the one that causes the problem!
Yes, but it's separate from the more obvious Transfer -> Transfer Type -> Auto/ASCII/Binary setting, which is what most people see. Different menus, dependent settings.
Auto would be fine if it didn't make the presumption about 'files with no ending are text lol'.