Module: Store Files on Disk

I am trying this module out on one of my small phorum site which have 1002 attachments both photos in posts and avatars and it works so far but there a few question I have.


I ran the script to covert everything over from db to hard file which stated 1002 converted over, is the attachment in db still left alone and I can delete them after doing some more testing to make sure it sucessfully converted over?


It may be my ISP but I notice after converting the attachment and then enabling the module. The embed image take longer to display them in full size after clicking thumbview. Not sure if it my ISP being slow tonight read next paragraph on why I couldn't compare with or without module.

I looked in the db and it look like all the attachment is still there that the convert script only made copies of attachment over to the hard file but when I turn the module off all the avatars are replace with a red "x" image not found and the photos in posts still display thumbnails but clicking on them does nothing not even bring up a full size photo until I had to enable the module again. So I assume once I enable and use this module then there no going back to db?

When the module is enable are all future avatar or photo or post attachment that is uploaded automatically saved to hard file now or only when someone is viewing it?


I am trying to really test this module because my backup are choking on a 8 gig db phorum attachment and need to get them out of the db to hard file to reduce the size of the mysql db.





Thank you
Bill



Edited 1 time(s). Last edit at 08/09/2008 11:28PM by CBiLL.

Quote

I looked in the db and it look like all the attachment is still there that the convert script only made copies of attachment over to the hard file

The info about the files stays in the db but not their content. So never delete the remaining part as you suggested above.

Quote

So I assume once I enable and use this module then there no going back to db?

yes, wouldn't make sense to duplicate the data, eh?
You can surely restore a backup of the db if you got one.

Quote

When the module is enable are all future avatar or photo or post attachment that is uploaded automatically saved to hard file now or only when someone is viewing it?

everything is saved to harddisk now.

---

Thomas Seifert

Quote
Thomas Seifert

Quote

I looked in the db and it look like all the attachment is still there that the convert script only made copies of attachment over to the hard file

The info about the files stays in the db but not their content. So never delete the remaining part as you suggested above.

Quote

So I assume once I enable and use this module then there no going back to db?

yes, wouldn't make sense to duplicate the data, eh?
You can surely restore a backup of the db if you got one.

Quote

When the module is enable are all future avatar or photo or post attachment that is uploaded automatically saved to hard file now or only when someone is viewing it?

everything is saved to harddisk now.

Thank you for the reply!

Now I understand it the attachment info that stay in db while the actual attachment is converted into hard file on hard disk.

Yeah I have a backup but going to do more testing on the module and I am thinking of staying with hard file instead of storing them in db.


Bill

I have a question about storage on disk location.


In module setting is a box where you put in the location of the directory where the attachment will be saved on disk then convert all files in DB onto the disk.

My quesiton is if I want to move it to a different location ie outside of the root dir of the website later on, will I just be able to copy or move the whole directory to a new location and update the module location setting where it been moved to?

Bill

Yes, that is possible.
Just keep in mind that there is a transition period and it might be wise to put the forums in read only mode or disable attachment uploads temporarily. Also remember to make the files / directory in the new location writable for the webserver.

---

Maurice Makaay
Phorum Development Team
my blog linkedin profile secret sauce

Quote
Maurice Makaay
Yes, that is possible.
Just keep in mind that there is a transition period and it might be wise to put the forums in read only mode or disable attachment uploads temporarily. Also remember to make the files / directory in the new location writable for the webserver.

Yes it what I am planing to do is to close or lock forums to read only mode before moving the directories over to a new location and update the module setting to the new path.

I have one other question is how are images stored on disk? I looked at them and it doesn't seem to be stored as the actual filename the images are uploaded instead it a file with no extentsion. I am guessing here that the Phorum already know it an image and display it as an image? Just wondering how it work cuz I thought it was going to be all on disk like it was uploaded to the DB converted back to file.

Thank for replies!
Bill

filename and meta data is stored in the db.

---

Thomas Seifert

I think there a bug with it but I am not really sure.

If you start a new post then attach a file and click preview you get an error similar to this

Quote

Warning: store_files_on_disk module: failed to write the data for file_id 104841 to the file system. The data will be kept in the database for now. The module will try to convert it from database to file storage, the next time that this file is requested. The error message is: Cannot create file storage directory "./attachments/95b/622/c18/e98/531/c84/d5f/c6f/543/ec1" in /home/******/public_html/mods/store_files_on_disk/store_files_on_disk.php on line 73

but after refreshing the browser and previewing again it will show the attachment without error.


Bill

I never have seen this problem. I run with embed images and file storage modules enabled on my site and I can preview messages without hassle. Somehow, the mkdir() call is reporting an erroneous state. Really strange that after the first call, the file seems to be written after all. Or is the attachment still in the database at that point and not written to disk?

Check the file permissions for the full tree. In your case, make it owned by nobody:nobody and check if all directories are set to at least rwx for the user. I'd suggest something like:

root$ cd <storage dir>
root$ chown -R nobody:nobody .
root$ find . -type f -exec chmod 660 {} \;
root$ find . -type d -exec chmod 770 {} \;

If that doesn't help, we'll have to try adding some extra debugging and/or error messaging to the module, to see why the OS is reporting a problem here. It makes no sense to me.

---

Maurice Makaay
Phorum Development Team
my blog linkedin profile secret sauce

Quote
Maurice Makaay
I never have seen this problem. I run with embed images and file storage modules enabled on my site and I can preview messages without hassle. Somehow, the mkdir() call is reporting an erroneous state. Really strange that after the first call, the file seems to be written after all. Or is the attachment still in the database at that point and not written to disk?

Check the file permissions for the full tree. In your case, make it owned by nobody:nobody and check if all directories are set to at least rwx for the user. I'd suggest something like:

root$ cd <storage dir>
root$ chown -R nobody:nobody .
root$ find . -type f -exec chmod 660 {} \;
root$ find . -type d -exec chmod 770 {} \;

I already set it nobody nobody but I think what happened is that it was busy setting 8 Gig worth of files to nobody nobody and I was test uploading and previewing the posts so when I didn't check to see if OS was done with setting file and the disk was probably still busy and the module couldn't write the file to the disk just yet.

I did some more testing afterward and it didn't do this anymore so the error probably only occur when the disk is under load performing a task.

Thanks for looking into it!

Bill
If that doesn't help, we'll have to try adding some extra debugging and/or error messaging to the module, to see why the OS is reporting a problem here. It makes no sense to me.