/albums/edit - gets mysteriously deleted every now and then

[GGallery]

title says it all... every 2 or 3 days, /albums/edit gets 'lost'.
Happned 3 days agao the first time... I first thought it was my fault after upgrading... it just happened again: no updates within 2 hours told me that there was something wrong: the 'edit' dir was completely missing.
I saw the nice little garbage collection you guys wrote but I can't see why and how this happened/happens (every 6-7k pics or so)

I did not change anything on the file IO functions... all changes are still cosmetic/adding of views etc.

[Tarique Sani]

There is a garbage collection routine in the picture editor which deletes old images and there is also a garbage collection routine in the upload script - did you change any of those?

[GGallery]

no, I didn't change anything there.

It happened the first time a couple days ago as the code was basically still 'out of the box'... I first suspected somebody hacking my box but everything seams to be OK, it's just the 'edit' dir that gets deleted once in a while... strange... unlink can not delete dirs and install.php is the only file with rmdir which I just completely removed. linux 2.6.6 ext3

[Tarique Sani]

@hyperion - can you look at the garbage collection in upload, I will look into the pictureEditor  once again today.

Yes, unlink should not delete dirs....

[hyperion]

I looked at this before when djboxny brought it up.  I could find nothing in the upload garbage collection routine that would delete the directory.  Indeed, as garbage collection is run every time an upload sequence is intitated, you would lose your edit directory anytime an upload occured.

I'll do another check, though.

[Tarique Sani]

Well I have looked into pictureEditor and it is fine - and there is no rmdir() anywhere....

Please let us know how and when this happens

[GGallery]

as I said, it just "happens"... directory disappears (it's a simple dir, not a link etc.)
I don't have any trouble with people disliking the gallery, no ddos etc. so far... I also checked the log files for any strange records but it 'looks' OK. Server is also very stable, the other stuff on it makes 30 times more load/IO than the gallery and no trouble.
/edit/ is chmod 777, could that have anything to do with it?
could perhaps some 'exotic' filenames (with dots etc.) have anything to do with it? (that would be my best guess)

I put a mkdir /albums/edit into my crontab for now just in case...

[GGallery]

I am seeing filenames such as:

kobus is a dork!.jpg

or

It_s[1]... Gilbert.jpg
Nikki Pretty... Very Pretty!!!.jpeg

in the db (yeah these kids are crazy...)

[GGallery]

update on that:
# cat /tmp/edit_dir_automatically_recreated
Tue Jun 15 23:49:00 PDT 2004
Thu Jun 17 03:32:00 PDT 2004
Fri Jun 18 00:45:00 PDT 2004

directory gets deleted every 1 or 2 days... I checked again the picture names and logfiles and every time this happened there was a lot of POST /upload.php activity e.g. I see 10 x POST /upload.php for the 1 minute timespan before the edit dir was automatically recreated on Fri Jun 18 00:45:00

(I have a crontab entry to record+recreate once they edit directory gets 'lost')

I am now completely deactivating the 'spring_cleaning' functions (let's hope it's that and nothing else/worse...) and will report back in 1 week at the latest.

[omniscientdeveloper]

Instead of deleting/deactivating it, try having it write the delete statement to a log file.

-omni

[hyperion]

GGallery,

What PHP version are you using? Also, I agree with Omni -- a log for the garbage collection function would be more helpful.  You might consider logging the $_REQUEST array, too.

In addition, the edit directory should not need execute permissions, and you could try removing unnecessary read/write permissions. (The server should be the only user accessing this directory.)

Do you have any system monitoring programs that watch user disk space usage?  They aren't common any more, but I've seen some written by evil university system admins that simply delete a directory that exceeds a user's quota.  I doubt that's the issue, but I thought I'd ask.

Again, I cannot see anything that would cause this problem.  The closest unlink could come to telling the system to delete the dir would be unlink(./albums/edit/.), but unlink should refuse.  I've found only one unlink bug for PHP, and it was an issue with 4.2.3 deleting actual files when it was supposed to delete a symbolic link.   

-Hyperion

[omniscientdeveloper]

Indeed.

I've added logging on this to the devel branch, but from looking at the code, I can't see where it'd cause this error, unless it somehow slipped past the is_dir check.

-omni

[GGallery]

I deactivated the 'spring cleaning' functions in upload.php and image_processing.php like this:

function spring_cleaning($directory_path) {
return;

and... it just happened again...

Box is dedicated and running apache+mysqld only... no other processes...

How can I activate detailed logging? what other steps would you recommend?

[SaigonK]

Anyone find the fix for this? it ihappens to me as well...i searched for a fix but to no avail....

[cr33p]

This has happened to me many times in the past, as well.  I can't say I've found a Coppermine fix, but I did manange to take care of the problem in another way.

If you are able to access a crontab on your hosting server (most cPanel hosts should allow this), just make this happen:

crontab -e

Code Select Expand


*/10 * * * * /home/xxxx/mkedit.sh


cat ~/mkedit.sh

Code Select Expand


#!/bin/bash
if test ! -s /home/xxxx/public_html/pics/albums/edit
then
       echo "that dir is not there"
       mkdir /home/xxxx/public_html/pics/albums/edit
       exit
else
       echo "that file is already there.  yay."
fi
exit 0


This just checks every ten minutes to make sure the albums/edit dir still exists, and recreates it if it is not there.