¿ªÔÆÌåÓý

Message (re-)numbering #messages #transfer


 

I want to clear up my initial misunderstanding of the transfer.

1. Are Yahoo message numbers preserved?
At first, I thought they were; now I think not - they are just a serial number assigned by g.io. #8391 on Y!G became #8197 in g.io

2. What happens to hyperlinks to a message? from within another message? from within a file? Are they transformed to the new path and message number?
Nada. The link is unchanged, pointing to the old Y!G message number. Aargh - that's going to take some tracking down.
?
3. Has anybody come up with a way to map g.io message numbers to the original Y!G #s?
Maybe something could be derived from a PB Offline download provided the g.io transfer was to an empty message archive and there had been no deletions on Y!G relative to the PBO download. Thinking that it could be as simple as a SQLite query on the PBO database.
?
4. Searching for such links is a problem. g.io seems to ignore the forward slash "/" in the search term. Is there an escape or control character to force it to be a literal? Does it even search within the hyperlink tag? Are there any search tips?

TIA,

Tom


 

On Mon, Oct 21, 2019 at 10:47 AM, Tom H wrote:
1. Are Yahoo message numbers preserved?
At first, I thought they were; now I think not - they are just a serial number assigned by g.io. #8391 on Y!G became #8197 in g.io
Tom -- As you note, message numbers are assigned in sequence, just as they were in Y!G. This is true whether posted by email, on the web page, or brought over via transfer.

Please also note that messages may have been deleted from the Y!G message base before it was ever transferred. This sometimes causes consternation when the transfer agent reports a number of messages transferred that is less than the message # of the last message that was posted to the group.

I hope you were able to follow that.?

2. What happens to hyperlinks to a message? from within another message? from within a file? Are they transformed to the new path and message number?
Nada. The link is unchanged, pointing to the old Y!G message number. Aargh - that's going to take some tracking down.
Expecting the transfer agent to parse every message for every conceivable cross-reference strikes me as unrealistic.

3. Has anybody come up with a way to map g.io message numbers to the original Y!G #s?
If anyone has done such a thing, it has not been reported since I've been here (approx 2 years).

4. Searching for such links is a problem. g.io seems to ignore the forward slash "/" in the search term. Is there an escape or control character to force it to be a literal? Does it even search within the hyperlink tag? Are there any search tips?
The search engine is capable of handling string literals, so try "/thisstring" instead. No guarantees that this won't escape the t.

More info at?/g/GroupManagersForum/wiki/Using-the-Search-Engine

Regards,
Bruce


Chromatest J. Pantsmaker
 

Since you have the PG Offline download, what database entry line number is Y!G message #8391 on?


 

Hi Bruce,

Thanks for the reply. You're a good source of expertise and experience.

3. Has anybody come up with a way to map g.io message numbers to the original Y!G #s?
If anyone has done such a thing, it has not been reported since I've been here (approx 2 years).
OK, I've come up with something. It relies on doing a PB Offline download of the Yahoo Message Archive and that there have been no deletions in it since the transfer to g.io in the range of messages that were transferred. I export the downloaded group to a SQLite 3 db3 file (one could work directly on its main ygroups.db3 file but, if there other downloaded groups in it, things can be confusing. I open the exported db3 file with a SQLite manager such as the free SQLiteSpy and run this script:
SELECT id+1-(SELECT MIN(id) FROM group_message) AS NewID, number AS OldID FROM group_message
;

That gives me a cross-reference like this, resorted descending:

?

NewID OldID
8776 8987
8775 8986
8774 8985
8773 8984

The NewID is the serial number assigned by PBO. My PBO d/l preceded the transfer by a few days and doing a manual binary search I can say that the NewID corresponds with that of g.io up to something between 1225 and 2500, above which there is a discrepancy of just 1. I'll have to redo a d/l and hope that nobody has been deleting stuff in the meantime.

The search engine is capable of handling string literals, so try "/thisstring" instead. No guarantees that this won't escape the t.
Searching on "/conversations/" brings up results for "conversations" and only one "/conversations/"
Searching on "groupname/conversations/" returns one result which is a link I am looking to correct. However, a SQLite query of the PBO database returns 7 hits.
SELECT number as OldID, TRIM(content) FROM group_message
WHERE content LIKE '%/conversations/%'
;

I'm sure there are more hyperlinks to messages in the messages in which some word other than "conversations" was used in the path. I suspect that might have been a change with Neo.

Point is, the g.io search tool seems deficient.

Tom


 

On Mon, Oct 21, 2019 at 02:17 PM, Tom H wrote:
OK, I've come up with something.
Good. Thanks for sharing with the others here in GMF.

Point is, the g.io search tool seems deficient.
That statement strikes me as a little harsh. Let's just say it isn't suitable for this particular application.

Regards,
Bruce


 

3. Has anybody come up with a way to map g.io message numbers to the original Y!G #s?
If anyone has done such a thing, it has not been reported since I've been here (approx 2 years).
So will it be a fixed offset, i.e.
Y!G??? GIO
300??? 125
325??? 150

etc? If so, we could put that offset in the header page or similar.

Second question: Could we specify a starting offset greater than the max Y!G #; that would avoid any confusion:
Y!G??? GIO
300??? 10125
325??? 10150




 

On Tue, Oct 22, 2019 at 11:36 AM, y@es wrote:
So will it be a fixed offset
That would be a definite Maybe.? If any messages were deleted on the Yahoo group, there will be a change in the interval/offset at that point when they're copied over.

Duane
--
Help: /static/help
GMF's Wiki: /g/GroupManagersForum/wiki
Search button at the top of Messages list
A few site FAQs: /static/pricing#frequently-asked-questions


 

On Mon, Oct 21, 2019 at 11:17 AM, Tom H wrote:
My PBO d/l preceded the transfer by a few days and doing a manual binary search I can say that the NewID corresponds with that of g.io up to something between 1225 and 2500, above which there is a discrepancy of just 1. I'll have to redo a d/l and hope that nobody has been deleting stuff in the meantime.
I redid the PBO d/l and that 1-off discrepancy persisted. Narrowed it down to groups.io failing to import a message that it did not report as a failure. It was #1990 in plain text. So I had to revise my query of the PBO exported database to skip over that record:
SELECT id+1-(SELECT MIN(id) FROM group_message) AS Gio_ID, number AS YG_ID?
FROM group_message WHERE number<1990
UNION?
SELECT id-(SELECT MIN(id) FROM group_message) AS NewID, number AS OldID?
FROM group_message WHERE number>1990
;
So it's not only deletions on the YG occurring between the PBO and Gio transfer but also missed messages by one or the other. It can be very labour intensive finding the discrepancies. I really wish Gio had the option to preserve YG message numbers when importing to an empty database or to allow them to be offset by some user defined value that assured the resulting numbers did not clash with any already in the Gio archive.

Tom


 

On Mon, Oct 21, 2019 at 11:19 AM, Bruce Bowman wrote:

Point is, the g.io search tool seems deficient.
That statement strikes me as a little harsh. Let's just say it isn't suitable for this particular application.
Not harsh at all, Bruce. It's an observation that the text search engine does not treat the forward slash character as a literal and, as a result, gives unwanted results. What other characters are special? And it missed most of the instances found by the other text search tools I tried - nothing fancy, no regexp. That's why it's accurate to say it is deficient when compared to typical text search engines.