Dead Galleries: PHP 4 3.2 release / Gallery v1.3.3-cvs-b4
|
mood
Joined: 2003-05-29
Posts: 29 |
Posted: Thu, 2003-05-29 16:54
|
|
Windows 2000 With PHP 4.3.2 RC4 and below Gallery worked fine. Updated PHP (kept old php.ini) and Gallery came up with an error that I should remove those Galleries in the /albums/ path because they weren't real galleries (?) Downgraded to PHP 4.3.2 RC4 and its OK again. Any ideas? What can I provide to help debug? Thanks Alex |
|
Posts: 8194
Strange. I have upgraded to 4.3.2 and nothing is going wrong with Gallery...You should probably upgrade your Gallery to the latest CVS version. See if that helps any...
Posts: 29
Tried the latest CVS and still no go.
Are you using Windows & PHP/ISAPI or CGI? or are you a sensible Linux user?
Alex
Posts: 8194
Hehe, read the username :wink:
Ya, my box is Gentoo Linux / Apache 1.3.27 / PHP 4.3.2
Hopefully PHP didn't b0rk any unserialization code or something similar with 4.3.2 on Windows...
EDIT: Just checked, nothing changed with the unserialization code between RC4 and -final, so that can't be the problem...Hmmmmmm
Posts: 29
well..... I guess I'll leave things as they are till either someone comes up for a fix for Gallery, or PHP or whatever.
Interesting is the fact that even PHP 4.3 2 CVS snaphsots worked and the release doesn't LOL
Thanks
Alex
(LLoRH8) (learning linux on red hat 8)
Posts: 974
Could there be a permissions issue?
Posts: 29
definitely not on this box where I tested the upgrade. Its a "default" W2K box..so security = 0 (or as M$ puts: Highly Secure)
Hmmm.....
Posts: 8194
Hehe. I don't really know what to say. If you want, try asking if anyone else had any problems -- http://php.net/support If you ever figure out what happened, please post back here. If we can help in any other ways related to this, please post back here too...
Posts: 60
I just got finished upgrading PHP on a box that sounds pretty close to the same:
Windows 2000
Apache 1.3.27
All of my galleries show up empty. I'm switching stuff back to 4.3.1 as well. Anyone know of a fix or have any new ideas?
Posts: 974
ISAPI or CGI?
Posts: 60
Sorry, forgot to put that in there.
I'm running as ISAPI and gallery 1.3.3.
Posts: 29
ffletch,
Pls try using 4.3.2 RC4, it should work. That way we have a pattern:
RC4 would work, release would be broken.
I'd love to report something at bugs.php.net but they'd "bogus" me without decent facts.
Alex
Posts: 60
Forgive my insulance, but are there binaries for 4.3.2 RC 4 available anywhere? I don't have a windows compiler handy.
Posts: 3474
Well... try 4.3.2, which was released yesterday. Windows binaries available.
http://www.php.net/downloads.php
Posts: 8194
Beckett, the problem is that 4.3.2 seems to be causing problems. If -RC4 worked, and 4.3.2 didn't, then there would be cause for more investigation...
Posts: 3474
Whoops! I need to go back to 1st grade and learn to read. Sorry!
Posts: 29
Sent ffletch2 a link to download PHP 4.3.2RC4 .
Wish you guys luck
Alex
Posts: 60
Folks-
Just tried PHP 4.3.2RC4 and it WORKED!
Whose got new ideas now?
Posts: 29
Good to know you were able to reproduce.
Thanks for your help
Alex
Posts: 660
For your information I'm having the same problem with broken galleries after upgrading to PHP 4.3.2
Windows 2000 Server/Apache 2.0.46
Gallery works fine again after downgrading PHP...
foffo
Posts: 29
By now, a warning on the "News" page would be nice
Posts: 8194
If anyone could come up with any information about this, that would be extremely helpful. I have tried to do some research, but have turned up nothing. I also don't have a Windows server, so can't verify this, though I have asked a few other with a Win server to look into this.
What happens if you try to create a new album? Does that album also become listed in the ones that are 'corrupt'? If you install a new, fresh version of Gallery, does it work?
If you come up with anything, feel free to post back here, or discuss it in #php on irc.freenode.net (IRC channel).
I'll make this topic sticky in the mean time.
Posts: 29
- I could provide you with FTP to a test gallery on a test machine if that would help.
(NT4-Sambar-PHP "whatever you need")
- If you install a CLEAN gallery with 4.3.2 , OR create new albums in your "broken" gallery it works.
It seems to haev something to do with reading gallery data created with 4.3.2RC4 or below.
Must be some very small dumb detail.
It would be interesting to compare the data before and after a PHP upgrade on a Linux box. (sorry,that I can't provide -yet-)
Mood
Posts: 60
I did the same things Mood described as a well (created albums in both a new, clean gallery and an upgraded "broken" gallery) and everything worked fine.
And I might be able to set up SSH to my windows box if someone is looking to a test bed. PM me if interested.
Posts: 29
5/31/2003: PHP version 4.3.2 has been released and has made some changes in the low level file handling process. As a result, there is a major change for Windows platform users. Any code that you have that uses the fopen('file','w'); call MUST BE CHANGED to fopen('file','wb'); or the file will be totally messed up! I can't emphasize this enough. KISGB will be compromised unless you either upgrade to KISGB v5.1.0 (once it's released) or modify the few places where KISGB uses this code. I have modified all the downloads for KISGB to fix this issue but left the version the same (v5.0.2) to avoid confusion with the upcoming release. This is NOT only related to KISGB - it is related to ANY/ALL PHP scripts on Windows.
http://www.gaylenandmargie.com/nuke/html/index.php
Posts: 115
I'm having the same issue. Could someone please email me a link or the binary for php 4.3.2 RC4? I would really appreciate it..
I'm really pissed that PHP made such a major change after RC4, that's wrong..
Anyway, your help is greatly apprecaited.
Marc
Posts: 29
Do we have any news on this issue?
The comments on the staring page seem to have disappeared.
Sadly the proposed fix didn't help.
I've mailed a friend who's in PHP Dev. in hope he may give us a hint or at least look into this thread and point us some usefull way.
Mood
Posts: 7994
Joan's got a candidate fix that will read and write files in binary mode. Once we've done some sanity testing on that we can try it out on your systems to see if it fixes the problem. You'll have to restore your .dat files from your backups, which you hopefully have and then try again with the new code to see if this time the albums don't get corrupted. I'll ask joan about posting her patch here.
Posts: 3473
The patch is attached. Instructions for installing a patch are in the user guide.
Before we can release this, we need to test two things: does it fix the problem; and does it break anything else? With that in mind, please restore your gallery from backups if you have them and please backup your gallery before using this patch.
Posts: 29
Bharat,
Thanks for the update.
my "old" galleries are in working order - I've setup a copy to check the updates before putting them to production (safety first?)
Looking forward to 1.3.4
Mood
Posts: 29
Joan, Bharat,
Applied patch - no errors -
Of 3 galleries with about 20 images each, two were OK, one was still broken.
ideas? can I provide something to help debug?
Alex
PS: The Gallery is stock - has no mods!
Posts: 3473
*** BAD ADVICE DELETED ****
watch this thread for Bharat's update
Posts: 7994
Ok, I finally got my Windows test environment back into shape and have what might be a very minor and simple fix for the problem.
The short answer:
Revert your Gallery to the stock -RC3 code (or whatever version you're using) and then edit util.php and in the getFile function, change:
if ($fd = fs_fopen($fname, "r")) {to:
if ($fd = fs_fopen($fname, "rt")) {The long description:
I set up my test environment so that I've got Apache2/PHP 4.2.2/Gallery 1.3.3 on one box (hereafter referred to as "4.2.2") and Apache2/PHP 4.3.2/Gallery 1.3.3 on another one ("4.3.2"). Both are brand new installs.
I found that I couldn't even log in on the 4.3.2 install. I created albums on both installs without difficulty. Individually, each worked just fine.
So then I simulated an upgrade by copying an album from the 4.2.2 albums dir over to the the 4.3.2 albums directory and then reloaded my 4.3.2 gallery. The first time I reloaded, I saw an error for that album, then on subequent reloads the album disappeared. This is the correct behaviour, because Gallery realizes that it can't handle the album and elects not to bitch about it every single time the page redraws.
Some investigation of the files shows that even though the album wouldn't load, all of its files were unchanged. Ie, they were completel y intact and not corrupted.
I then (after some digging) applied the short patch that I included above on the 4.3.2 box, and then could all the albums in the 4.3.2 gallery (both the ones that originated from 4.3.2 and the ones that I copied from 4.2.2).
So, it looks good. Hopefully all the monkeying around has not trashed your .dat files, but theoretically it shouldn't have (I couldn't get Gallery 1.3.3 to toast my .dat files during this process, but perhaps if you're running an earlier version they might have gotten damaged
). If this patch works for you guys I'll commit it asap.
Posts: 29
I'll try this tonight when the server is less busy.
In the meantime I had contacted Melvyn from PHP Dev, and he traced Gallery and our problem and seems he found a couple of errors in the 4.3.2 release. Wez, another PHP guy is looking thru the code and they'll send me a snapshot to test...
This is gonna be fun! I'll let you know what happens with 4.3.2 Release and with the snapshot.
Alex
Posts: 29
Bharat,
Yeah!
Tried your above fix with 1.3.4 RC3 albums using PHP 4 3 2 W32 on a TEST gallery and it worked.
Give me a couple, of hours and I'll update 3 galleries in production.
Will let you know the outcome real fast...
Alex
Posts: 29
Bharat,
the test inst I just "fixed" has a trashed gallery
damm!
Posts: 29
Bharat
Tried on production box - same effect.
Its always the first gallery - don't have sub gals.
If you want my gall & albums to check it... (they're not too large), pls mail me.
Alex
Posts: 29
We're getting there:
Wez Furlong from the PHP group sent me this a while ago:
----------------------------
Subject: Re: changes from 4.3.2 RC4 to 4.3.2 Release/W32/ISAPI
Technically, gallery should have been using binary mode for those files
if all it is doing is storing serialized data.
However, since they were created in text mode, you now need to
explicitly load them in text mode as a horrible kludge.
I apologize for this breakage, but the change was needed to bring win32
apache into line with CLI and CGI sapis. It will also encourage people
to start writing more portable code.
Text-mode is an evil invention that makes assumptions about the number
of bits in your characters and transparently mangles newlines as they
are read or written to the file.
Relying on implied text-mode really is a bad idea, since you have no
real way of knowing which combinations of PHP versions and SAPI have
which defaults. Apache could even be switched to a different mode by
other apache modules.
In light of this, I urge you to consider writing a script to convert the
text mode files into binary mode for your next major release, and then
default to using binary 'b' instead of 't' in your fopen calls.
convert.php:
<?php
$src = fopen($filename, 'rt');
$srcdata = "":
while (!feof($src)) {
$srcdata .= fread($src, 8192);
}
fclose($src);
$dest = fopen($filename, 'wb');
fwrite($dest, $srcdata);
fclose($dest);
?>
--Wez.
--------------------------------------------------------------------
Hoping for comments
Alex
-------------
Posts: 7994
FYI, this is the gating bug that's preventing us from getting 1.3.4 out the door. We are giving it as much time as we can! Unfortunately I had a little crunch at work and was there till 4 AM and had to get up at 8 AM this morning so I'm a little groggy at the moment.
So let me recap. You had a test gallery which was working on 4.2.2, then you upgraded it to 4.3.2 and it was broken. You then installed Gallery 1.3.4-RC3 with my one-line fopen() patch and it fixed the problem temporarily. Then the problem came back again? Is that accurate?
Can you send me a pointer to your test gallery so that I can look at the .dat files? I'll figure out how to get them working with my -RC3 + fopen-patch install. As of now ve been unable to get my test gallery to fail with the latest fopen() patch so I need to see what the broken data looks like...
Posts: 29
Recap:
it was working with 4.3.2 RC4 - when I changed to 4.3.2 Release the galleriess were broken.
I'm redoing the "broken galleries with your latest patch and willl mail you the FTP data to the gallery tree asap
Thanks
Alex
Posts: 7994
Ok party people, I've got some good news for you.
First, a terminology check. When Mood is saying dead galleries he's really talking about albums that show up as having no photos. This threw me for a bit; I thought that he meant that his entire gallery was toast in some inexplicable way. He sent me the URL to his Gallery offline and I was able to pull down his album.dat and photo.dat files from his broken album (the Home-Outside one, Mood) and experiment with them on my WinXP box.
The good news is that I figured out what's going wrong. I'll describe the problem in detail below. The really good news is that we've made a patch that fixes the problem and it's available here:
v1.3.4-final-cvs-b1
Install this version on top of your 1.3.4-RC3 install, just as if you were doing a normal upgrade. It should automatically fix all of your broken albums and should not break any new ones. Please test this as soon as possible because if it doesn't have any issues we're going to release it as the 1.3.4 final release very soon.
Ok, now for a description of the problem. Mood called in some heavy hitters from the PHP team and they provided us with enough information to really understand the problem. It turns out that Gallery has been saving its data files in text mode instead of binary mode since the very beginning. In binary mode, when Gallery writes a newline to the file, it gets stored the same way on Windows as it does on Unix. But in text mode it adds an extra carriage return to every newline when writing the file on Windows because that's the Windows standard for line terminators.
Gallery never specified text or binary mode and PHP 4.2.2 and earlier defaulted to reading and writing files in text mode. But in 4.2.3 they flipped it so that it defaults to reading and writing files in binary mode.
Even so this won't cause a problem unless you happen to put a newline in a comment, caption, description, etc. in your album. Then the bad stuff hits the rotating blades.
The fix is twofold:
I hope that clears things up![/]
Posts: 29
Bharat,
Got it, installed, its working...... APPLAUSE!
Cannot try on production till tonight.
So glad you were able to figure it out with the PHP guys.
Actually, we hadn't realized that not only "Home-Outside" was broken - There was also one album missing. This version fixed the stuff in such a way that all albums showed up, in good shape.
Again BIG thanks to all you guys & gal who took the time to look into the issue.
BTW, Small detail: the version in the tar file I downloaded seems incorrect: "Gallery v1.3.4-RC3"
Will let you know how the updates went
Mood
Posts: 3474
Small typo. Bharat fixed that now.
Posts: 115
I still have one album, it's a sub album: http://waffull.com:9700/gallery/palagio
That's coming up bad. This is after upgrading to: v1.3.4-final-cvs-b1
I still get the error message when logged in on the main album page that the palagio album is corrupt..
All other albums seem to be working properly..
Any thoughts?
Marc
http://waffull.com/gallery
Posts: 29
I suggest you mail bharat that album's dat files asap so he can take look.
Mine have all survived. One of my clients had heavy nested albums..all here.. (was lucky)
Mood
Posts: 115
Will do, thanks.
Marc
Posts: 29
Could be time someone removed this sticky.
Bharat found the cause, fixed and we're all happy campers!
Big thanks to the Gallery Team for all your help
Mood
Posts: 3474
Un-stuck. Or... Un-stickied? Un-stickified?