On Mon, 2008-11-03 at 02:27 -0500, Chris Frey wrote: > On Sun, Nov 02, 2008 at 12:32:38PM -0500, Martin Owens wrote: > > Ah figured it out, I had barry installed from the ubuntu repositories as > > well; so it looks like the libbarry was conflicting. > > > > Once I'd cleared it out and got it using the newest version, it worked! > > Great news! > > I've changed the sources so that bfuse is now installed in /usr/bin instead > of /usr/sbin. I noticed that 'fusermount' was in /usr/bin, so the bfuse > driver might as well be too, since it is meant to be run by users. > > > > OK so here are my thoughts. Currently the fuse mount is showing all the > > databases. There may be a deeper level which needs to be shown instead > > though. > > I was thinking of: > > /PIN/Database/Record > > for directories, and then inside record directory, would exist the > following files: > > everything A file that shows everything, similar to > what exists now. > > [field_name1] Each field of each record, as a file. > [field_name2] For example, WorkPhone and WorkPhone2, for > etc... a contact, would be individual files. This > would open up the possibility of writing > to those files as well, in the future. > > Also, in the root mount point, there exists error.log, which should contain > any USB or Barry error messages, once exception handling is done better. > > Bfuse might remain experimental across a couple releases, depending on > the speed of development. > > > > By blackberry Pearl mounted to /mnt/mount1 showing up as 204c09c5 > > > > So as I said in my previous email, I think the fuse mount needs to mount > > one device at a time. This is so mounting can be handled by existing > > infrastructure such as hal and gnome-auto-mount. > > That's acceptable to me. Perhaps by PIN number, since hal will have that > number available. :-) > > Note that while a Blackberry is mounted, it is unavailable to other > uses (at least until Rick Scott's kernel driver is finished and I add > support for that to the library).
Done! Well, maybe not done, but usable :) As of a few minutes ago it should be working on FC3, FC4, and CentOS 5.2. It provides a /dev/bbdesktop[0-127] and /dev/bbmodem[0-127]. /dev/bbmodem... can be used just like any modem device with pppd. I only do the IP Modem stuff so far, I have no devices left that _need_ the SerData stuff. /dev/bbdesktop... looks just like the rfcomm device for BlueTooth, and the old serial devices. I use it with XmBlackBerry -device /dev/bbdesktop0 and pppd /dev/bbmodem0 call BlackBerry I took a quick look through the barry library, but couldn't determine where the best place to add a device file argument would be. All but the lowest level of comms is the same. Instead of adding on the socket and length, you add a header checksum and footer .... > > But for now, I'm not sure that you would want to automatically mount > a Blackberry. It might be better to have as an on-demand sort of thing. > > Maybe this is what you had in mind all along, and I'm just misunderstanding. > > > > Looking deeper I find these databases: > > > > Address Book, Browser Folders, Certificate Options, Folders, > > Message List Options, PIN Messages, RMS Databases, Tasks Options, > > Address Book Options, Browser Messages, Content Store, > > ... (let me know if you want a full listing) > > All these databases are available through the library, and through > 'btool', etc. > > > > the interesting one looks to be Content\ Store, inside this directory: > > > > /mnt/mount1/204c09c5/Content\ Store > > > > We find lots of files which contain information about directories. This > > looks to be the data we want to expose on the fuse mount. So how ever we > > can extract the file system from the 'Content Store' database to the > > bfuse or perhaps a bcontentfuse mount need some research. If you want > > Chris I can have a look into it. > > We will need to reverse engineer the Content Store record format, write a > parser and builder, and then expose the parsed data via FUSE. > > If you want to document what the fields mean, their format, offset, size, > etc, that would be a great first step, and then it should be straightforward > for me to write a parser / builder. (If someone wants to volunteer writing > that too, let me know!) > > A lot of field data is in the format of [[size] [type_code] [data]]. > I don't know if Content Store follows that format though. > > Thanks for volunteering, and for testing! > > - Chris > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Barry-devel mailing list > Barry-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/barry-devel ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Barry-devel mailing list Barry-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/barry-devel
