Keyboard Shortcuts
ctrl + shift + ? :
Show all keyboard shortcuts
ctrl + g :
Navigate to a group
ctrl + shift + f :
Find
ctrl + / :
Quick actions
esc to dismiss
Likes
Search
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?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.? Expecting the transfer agent to parse every message for every conceivable cross-reference strikes me as unrealistic. 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 |
||||||||||
Hi Bruce, Thanks for the reply. You're a good source of expertise and experience. 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: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).
That gives me a cross-reference like this, resorted descending: ?
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. 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.
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. 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 |
||||||||||
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 offsetThat 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:
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. |
to navigate to use esc to dismiss