MyBB Community Forums - Merge System 1.6 and SMF 1.1 attachments problem.

Pages: 1 2 3 4 5 6 7

Yes now seems to be ok Smile

Now i've some problem with WampServer in windows seven.
In second step, when i try to import "user" i receive "connection interrupted" (browser page error) if i try with http://127.0.0.1/mybb/convert/index.php.
Instead, if i try with http://localhost/mybb/convert/index.php, i will be redirected to http://www.localhost.com/mybb/convert/index.php (blank page).
Maybe, tomorrow, i try directly in my hosting.

(2010-09-28, 07:57 PM)CaptOblivious Wrote: [ -> ]What about the post ID issue, wherein attachments get attached to the wrong post? I tried tracing the functions responsible for determining the new post ID from the old post ID, but there's a lot going on in there for me to follow. Is there anything I can do to help debug this issue?

I can confirm this problem as it happens with my install as well. I get a bunch of errors during attachement import and afterwards images are attached to the wrong posts.

Warning [2] mime_content_type(): File or path not found 'jpg' - Line: 130 - File: convert/boards/smf/attachments.php PHP 5.3.2-1ubuntu4.5 (Linux)
File 	Line 	Function
[PHP] 	  	errorHandler->error
/convert/boards/smf/attachments.php 	130 	mime_content_type
/convert/resources/modules/attachments.php 	39 	SMF_Converter_Module_Attachments->convert_data
/convert/boards/smf/attachments.php 	105 	Converter_Module_Attachments->insert
/convert/index.php 	970 	SMF_Converter_Module_Attachments->import

I tried out the latest svn from the stable-1.6 tree (yes this time I used all files :-)). Dylan already asked me for db access, so maybe he can squash this bug as well while having a visit.

And yes, my db is ancient as well, so it has both types of attachment file name conventions in there as well, might be part of the problem.

I tried the merge with default prefilled settings, so during the attachment part, the merger suggest the absolute filesystem path to my old attachment directory (without a / at the end) and I accepted that without any change and got the above described problems.

There is also a bug in the imported access rights of (at least) guests/aka no users, but I guess this has to go somewhere else.

ok, just compared my old and new attachment directory. 59 files made it over, out from 1628. Can't really say what makes these 59 so special to actually make it compared to the others.

interesting enough the mybb attachment table in the db has

Showing rows 0 - 99 (1,313 total, Query took 0.0016 sec)

entries.

which btw include entries pointing to avatar pictures and I thought you mentioned them not being migrated at all?

digging a bit more it seems to me this here is wrong, check out the attachment name row. I take it this should be the filename the forum uses for the attachment right? But then this shouldnt have the same name?

[attachment=20083]

SELECT DISTINCT attachname
FROM mybb_attachments

gives me

Showing rows 0 - 70 (71 total, Query took 0.0210 sec)

at least thats a lot closer to 59 then to 1313, but still odd.

Once I take a look at Tupsi's database I'll hopefully be able to shed more light on whats going on. However Tupsi, It may be your version of PHP that is causing the error with mime_content_type(), as that function has been deprecated. See Bug 1250 for more information... though you really shouldn't have it with 5.3.2... its been deprecated but not removed yet AFAIK...

try changing line 130 from:

$insert_data['filetype'] = mime_content_type(get_extension($data['filename']));

to:

$insert_data['filetype'] = mime_content_type($data['filename']);

As it should be getting passed the whole filename according to this.

ill try that in a minute, just something to check for the generell process:

Do I have to setup the fresh installed mybb in a way it would allow bigger attachments then as default if the merger will attempt to move these or does the merge ignore these settings in general and only new files have that problem?

(2010-10-05, 01:59 PM)Tupsi Wrote: [ -> ]ill try that in a minute, just something to check for the generell process:

Do I have to setup the fresh installed mybb in a way it would allow bigger attachments then as default if the merger will attempt to move these or does the merge ignore these settings in general and only new files have that problem?

The Merge System ignores the settings Smile

If that does fix the issue, please file a bug report about it and I'll fix it either this evening or tomorrow Smile

I'm out for the day, breakfast is almost done cooking and then I have a lot to do today. Later guys Smile

(2010-10-05, 01:42 PM)Dylan M. Wrote: [ -> ]Once I take a look at Tupsi's database I'll hopefully be able to shed more light on whats going on. However Tupsi, It may be your version of PHP that is causing the error with mime_content_type(), as that function has been deprecated. See Bug 1250 for more information... though you really shouldn't have it with 5.3.2... its been deprecated but not removed yet AFAIK...

try changing line 130 from:
$insert_data['filetype'] = mime_content_type(get_extension($data['filename']));
to:
$insert_data['filetype'] = mime_content_type($data['filename']);
As it should be getting passed the whole filename according to this.

the error got a little more "meaningful" with your change, but its still an error showing up:

Quote:Warning [2] mime_content_type(): File or path not found 'Wedding_10.jpg' - Line: 130 - File: convert/boards/smf/attachments.php PHP 5.3.2-1ubuntu4.5 (Linux)
File Line Function
[PHP] errorHandler->error
/convert/boards/smf/attachments.php 130 mime_content_type
/convert/resources/modules/attachments.php 39 SMF_Converter_Module_Attachments->convert_data
/convert/boards/smf/attachments.php 105 Converter_Module_Attachments->insert
/convert/index.php 970 SMF_Converter_Module_Attachments->import

so instead of just "jpg" it now tells me the full name of the file; which seems plain wrong, as its the original file name and not the attachment-directory-filename.

Thats whats wrong, it needs the attachment filename. I just wonder why I never encountered this before. Let me have some time and I'll give a proper fix for this.

and whats even stranger is that fact that I get SOME attachments moved even though that error gets up. With that error it seems to me that it should take place with every attachment as non there have the original filename in the forum dir, only the db knows that one.

Hopefully if you find a fix for this one, it will fix the "wrong attachment in post" one as well as it feels related.

think i found something.

check my db. the attachments there, not every entry has a file hash. Now the first entry with no filehash "30699Hits.jpg" gets a distinct new filename in the merge process and every other file which has no filehash now gets the same mybb filename in the process ("post_0_1286291022.attach"). Only entries with a different filehash get a new filename for mybb in the merge.

Sounds like you cant rely on the filehash for your convertion as old db entries dont have the filehash. You can see in my db that the file hashs start only at ID 1769. Only 99 out of 137 entries have a filehash.

[attachment=20093]
[attachment=20094]

Although ALL files in the forum dir seem to have some sort of hash attached to their filename, not only the new ones after ID 1769.

For instance

71_Maws_down_jpg3b89404d3f3da2c699f9cde04d9981d0

has no has in the database as you can see on one of the screenshots (2nd one, last entry).
For the above function to work, you would have to add the attachment ID and "_" in front of the file and that hash number behind it. Although I am clueless atm where it comes from and how smf itself find thats file again, because the hash is not in the database it seem to compute it on the fly when needed?

(2010-10-06, 06:30 AM)Tupsi Wrote: [ -> ]and whats even stranger is that fact that I get SOME attachments moved even though that error gets up. With that error it seems to me that it should take place with every attachment as non there have the original filename in the forum dir, only the db knows that one.

Hopefully if you find a fix for this one, it will fix the "wrong attachment in post" one as well as it feels related.

We'll see. I'm hoping so too, like I said before I couldn't duplicate that from my other test databases. Now that I have a copy of yours and I can duplicate it, it should help.

Quote:think i found something.

check my db. the attachments there, not every entry has a file hash. Now the first entry with no filehash "30699Hits.jpg" gets a distinct new filename in the merge process and every other file which has no filehash now gets the same mybb filename in the process ("post_0_1286291022.attach"). Only entries with a different filehash get a new filename for mybb in the merge.

Sounds like you cant rely on the filehash for your convertion as old db entries dont have the filehash. You can see in my db that the file hashs start only at ID 1769. Only 99 out of 137 entries have a filehash.

Although ALL files in the forum dir seem to have some sort of hash attached to their filename, not only the new ones after ID 1769.

For instance

71_Maws_down_jpg3b89404d3f3da2c699f9cde04d9981d0

has no has in the database as you can see on one of the screenshots (2nd one, last entry).
For the above function to work, you would have to add the attachment ID and "_" in front of the file and that hash number behind it. Although I am clueless atm where it comes from and how smf itself find thats file again, because the hash is not in the database it seem to compute it on the fly when needed?

This is what the get_raw_filename() function does, and why there was a fix for that (provided by CaptOblivious) for databases such as yours that have a mix of the old and new schemes.

(2010-10-06, 11:09 AM)Dylan M. Wrote: [ -> ]This is what the get_raw_filename() function does, and why there was a fix for that (provided by CaptOblivious) for databases such as yours that have a mix of the old and new schemes.

but it seems to me that this function isnt called/used correctly then, as the import error says nothing neither about an attachment ID nor and md5 hash at the end, just an error that the normal filename could not be found (which is of course correct).

btw. you ment generate_raw_filename(), didnt you? couldnt find get_raw_filename() in attachment.php

after rereading attachment.php a bit, I dont see why convert_data can return valid results with

$insert_data['filetype'] = mime_content_type($data['filename']);

at all, as so far, I was under the impression that $data['filename'] holds the real filename from the old smf db, so how would the php function mime_content_type conjure a forum filename out of it to determine the file type?

I am beginning to think that your test installations dont have that function enabled and so that part of the convert_data() never gets used.

Ill commented that out and trying to import again now.

Pages: 1 2 3 4 5 6 7