Bug 162416
| Summary: | GDBM database dump/restore utility to migrate files between architectures | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Matthias Saou <matthias> | ||||
| Component: | gdbm | Assignee: | Marek Skalický <mskalick> | ||||
| Status: | CLOSED UPSTREAM | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | rawhide | CC: | databases-maint, hhorak, nalin, rvokal, sergio | ||||
| Target Milestone: | --- | Keywords: | FutureFeature | ||||
| Target Release: | --- | ||||||
| Hardware: | x86_64 | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Enhancement | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2017-05-16 12:07:38 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
|
Description
Matthias Saou
2005-07-04 11:31:10 UTC
Some more information on the problem : - With testgdbm, on a file that works fine on an i386 host : ./testgdbm -g ~/stats.db gdbm_open failed, File seek error - Strace of dumpgdbm on that same file : "lseek(3, 35184372097024, SEEK_SET) = -1 EINVAL (Invalid argument)" (see the attached strace.txt file) So it seems to be some kind of file seek error, for whatever that might mean. Created attachment 116328 [details]
Output from strace dumpgdbm
More digging into the issue : - Recompile the "testgdbm" program with "make progs" in the gdbm sources. - On the x86_64 machine, run "testgdbm -g test.gdbm" and insert 2 entries. - Copy the file over to the i386 machine, run "testgdbm -g test.gdbm", it seems to work, but the database doesn't contain the inserted entries, it only contains one empty key/value pair. The other way around : Doing the exact same operation but inserting on i386 and trying to read on x86_64 results in testgdbm's "gdbm_open failed, File seek error" error message. So it seems that GDBM files created on i386 and x86_64 are incompatible. This is probably not normal, as endianess is the same, so sompatibility could probably be achieved. gdbm databases are, afaik, wordsize specific. Cc'ing Nalin, who I believe looked at this once. Unfortunately (for me), you are right. I got this reply from the current maintainer : "Of course it works. You're accessing a 32bit GDBM file with a 32bit library. You can not, however, access a 32bit GDBM file with a *64bit* library. GDBM files are not portable between different architectures." So, I guess I could nevertheless change this bug to an RFE, to include some kind of dump/restore utility that would allow moving GDBM files across architectures? I'm pretty sure I won't be the last to move GDBM files from i386 to x86_64 servers... The utility that did it for me was gdbmtext : http://starynkevitch.net/Basile/gdbmtext.c Which requires the following change to not segfault in some common cases when importing : --- gdbmtext.c.orig 2005-07-04 17:15:06.963692448 +0200 +++ gdbmtext.c 2005-07-04 19:10:02.505410768 +0200 @@ -71,6 +71,7 @@ indatum (char **ppc) xbuf[1] = pc[2]; xbuf[2] = xbuf[3] = 0; *(wp++) = (char) strtol (xbuf, 0, 16); + pc += 2; } else *(wp++) = *pc; }; Anyone willing to review that gdbmtext.c piece of code and get it included either in upstream gdbm or at least in the Fedora/RH packages? Some basic dump/restore functionnality is something really valuable when the format is binary incompatible across supported architectures... Changing this to a RFE while I'm at it. Move to Fedora Is anyone still interested in providing a gdbm "migration tool"? User pnasrat's account has been closed Hi, I am new owner of this bug. I will have a look at the gdbmtext.c and will decide whether we should try to add this package to the distribution. Cheers Ondrej (In reply to comment #8) > Is anyone still interested in providing a gdbm "migration tool"? Hi , I am facing this kind of problem , but I need a dbm which is not architecture dependent , because I need read on 32 and 64-bit platforms , Any suggestion ? Thanks, Hi Sergio, please ask on a public mailing list, only very few people read Bugzilla entries. This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. Note, that a new gdbm-1.9.1 (already in Rawhide) provides different magic values for 32 and 64 bits, so we can discover what system the file was created on if we use this new version. Even though it is not a solution, I hope it can help at least a bit. This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. Some weeks ago I found that sqlite3 is a very good alternative and also seems that is platform independent [1] [1] http://stackoverflow.com/questions/15024658/are-sqlite3-databases-are-platform-independent Well, sqlite3 might be suitable alternative in some cases, but it is generally very different product. Gdbm in latest versions contains gdbm_dump (and gdbmexport) tool which allows exporting of database to Flat Format (see gdbm doc). Also it is possible to install gdbm.i686 on 64-bit systems to support reading of gdbm databases created without largefiles support. Feel free to reopen. Or for new features create bugs in upstream tracker - https://puszcza.gnu.org.ua/bugs/?group=gdbm |