Attachments as files

Well after alot of time leaving it in the beta hacks forums without any problems, I'm now moving it to the Full Releases, I'm satisfied that there isn't any bugs that need to be addressed. Thanks to Jawelin he pointed out most of the mistakes through alot of his testing.
I've attached it as an installer file here, as it needs to make changes to the database. Two new rows to settings and a new column in the attachment table.

Scott

Updated some more

Note the > is missing off the bottom of the file after the ?, add it before trying to install

[Kamui Shirou]

Hey,
nice hack, but somehow my hash for the files disappeared. now it only shows a red cross. how can i get them back. the files are still in the attachment folder, it's only the hash query in the database.

[Marco van Herwaarden]

I hope you are aware of the fact that this is a hack for vB2?

[jjj0923]

I've been using this hack for over two years now and just ran into my first problem... the datatype for the index field "attachmentid" is tinyint - length 5 and my forum members have posted 65,535 images to date and now they cannot add any more...

I'm reluctant to go in and change the data type to medint or integer and expand the length of the field without consulting with someone first. Has anyone else run into this problem and if so - how did you get around it.

upgrading to V3 is just not in the card for me until the end of september because of a very busy schedule..

any help would be appreciate - especially if you are using this hack on V2 and have oversome this problem yourself..

thanks in advance...

- jeff

[Marco van Herwaarden]

I don't know the code, but it is very unlikely that the code will fail if you change the datatype to a longer integer type.

But you better check if there are not other tables that are refering to the same column, they would have to be changed also.

[jjj0923]

well - the length is 5 character does a medint or integer fields require more characters?

[Marco van Herwaarden]

Are you talking about usable 'characters' (positions) or internal storage in the database?

Yes it will increase, that is why it will be able to hold a higher value. And like i said, modifying all columns in the database that reference this column should probably be enough.

[Azeem]

Hi so which directory do I upload this to? (Newb here) and wil this solve my problem of not being able to upload large files (on shared hosting cant change max upload size)

[Zachery]

You know this mod is for vBulletin 2 and is a default feature for vB3

[bitbender]

Originally Posted by Zachery

You know this mod is for vBulletin 2 and is a default feature for vB3

Yep, completely.

But, until we can get it to work consistiently when merging the data back to the DB before running the VB 3.5.* upgrade script, it's still a bone of contention. Even at the VB 3.5 (gold) level, it does not seem to recognize the fact that the attachments are in files versus data base, even if you enable it. That's a problem (unless I am doing it wrong, and I'd LOVE it if someone showed me a better way here).

That implies to me that anyone using the Attachments As Files hack HAS to get the attachments loaded back into the filedata variable before we can proceed with the move to 3.5. When I try to upgrade to vb 3.5 without merging the attachment data back into the DB, the upgrade script fails when it goes to alter the attachments table on or about step 10/42. So, for my hacked up situation, I have to perform the process.

I am having a problem now with losing about 2 thousand of the latest attachments. I rewrote attachment_upgrade.php to to;
a) Check the return codes on each of the DB and File calls being made
b) count of how many attachment records are in the returned array
c) Write a message every 500 attachments saying "nnnn have uploaded sucessfully"
c) count of how many failed upload
d) write out some basic messaging of these actions - total in array, total uploaded, total failed..

While the script runs, it matches the count of records I see in my live DB, and I get no "file not found" messages. Also, it appears that the attachment table is back to being the huge behemoth it once was when the filedata variable contained the attachment data(800+ Meg).

One cannot remove the hash field from the attachment table prior to running the attachment_upgrade.php script as it depends on that field to help determine the file name to read into the filedata variable. Although I have tried to remove this after I did run the attachment_upgrade script to see if that made a difference.. It didn't. As a matter of fact, it caused a loss of rows.

The problem is that when I take this DB into VB 3.5 it seems to lose all attachments posted after a certain date (like 1/5/2005 thru current day). Anything older than that is ok, as well as any new ones updated.

I have tried a ton of variations to see what in creation is happening. I cannot proceed with losing 2 thousand+ attachments.. Any Ideas, or insights?

[Zachery]

Originally Posted by bitbender

Yep, completely.

But, until we can get it to work consistiently when merging the data back to the DB before running the VB 3.5.* upgrade script, it's still a bone of contention. Even at the VB 3.5 (gold) level, it does not seem to recognize the fact that the attachments are in files versus data base, even if you enable it. That's a problem (unless I am doing it wrong, and I'd LOVE it if someone showed me a better way here).

That implies to me that anyone using the Attachments As Files hack HAS to get the attachments loaded back into the filedata variable before we can proceed with the move to 3.5. When I try to upgrade to vb 3.5 without merging the attachment data back into the DB, the upgrade script fails when it goes to alter the attachments table on or about step 10/42. So, for my hacked up situation, I have to perform the process.

I am having a problem now with losing about 2 thousand of the latest attachments. I rewrote attachment_upgrade.php to to;
a) Check the return codes on each of the DB and File calls being made
b) count of how many attachment records are in the returned array
c) Write a message every 500 attachments saying "nnnn have uploaded sucessfully"
c) count of how many failed upload
d) write out some basic messaging of these actions - total in array, total uploaded, total failed..

While the script runs, it matches the count of records I see in my live DB, and I get no "file not found" messages. Also, it appears that the attachment table is back to being the huge behemoth it once was when the filedata variable contained the attachment data(800+ Meg).

One cannot remove the hash field from the attachment table prior to running the attachment_upgrade.php script as it depends on that field to help determine the file name to read into the filedata variable. Although I have tried to remove this after I did run the attachment_upgrade script to see if that made a difference.. It didn't. As a matter of fact, it caused a loss of rows.

The problem is that when I take this DB into VB 3.5 it seems to lose all attachments posted after a certain date (like 1/5/2005 thru current day). Anything older than that is ok, as well as any new ones updated.

I have tried a ton of variations to see what in creation is happening. I cannot proceed with losing 2 thousand+ attachments.. Any Ideas, or insights?

You are moving from 2.x with this hack to 3.5?