This took a bit longer than I expected but I've finally gotten this project to the point where I feel comfortable I can go public with it. And reveal just what the heck has been sucking down all my time recently. :)

I've developed a mountable Sony Reader Filesystem.

What the heck is that you ask? Well rather than an application such as the wonderful libprs500 or the Connect application supplied by Sony this piece of code isn't an application.

You insert a SD card and the operating system uses some code to read the contents of that SD card and present the contents as files and folders. This piece of software does the same task, but for the Sony Reader.

You can then use your favorite tools to explore and modify the contents of your Sony Reader. On the Mac you can use Finder or Terminal. If you are writing an application to bind ebooks or RSS feeds onto the Sony you can write the data to the Sony Reader as if it were a regular collection of files and folders on the computer itself. For example, you can have Word 2004 export an RTF file directly to the Sony Reader.

The code is written using FUSE and libusb. This allows the same code base to work on Mac, Linux and FreeBSD. There is no Windows version, but heck: you've got Sony's CONNECT software on Windows right, you don't need this. :D

First release is for the Mac. You will need Mac Fuse from Google: http://code.google.com/p/macfuse/ and libusb: http://www.ellert.se/PKGS/libusb-0.1.12/10.4/libusb.pkg.tar.gz.

Code later today.

Such a tease!!!!!!!!!!!!!!!

So, does this transparently convert folders in the FUSE filesystem to "collections" on the reader. If so, that totally rocks. Otherwise, this is still very nice. Thanks.

Nice. I had planned on doing this at some point, but the fuse python bindings aren't stable enough. Incidentally, there is another project to do this at http://code.google.com/p/prs500fs/

Source, please! This sounds like a lovely tool to have available.

Xenophon

Interesting. I look forward to trying it out.

Oooh, this sounds promising. I can't wait to try this! :)

I had developed a tremendous amount of diagnostic cruft as I slugged it out with the FUSE/libusb (each had their own unique pound of flesh to collect) and removing it all took a bit more time than I expected. My apologies.

This is a Mac OS X 10.4.8 Intel executable. PPC/Installer etc in the future.

You can look, you can read, no writes yet.

You need to have the Google port of FUSE installed and the libusb as linked in the first post in this thread.

Example of using it in Terminal, with Sony Reader plugged in...
mkdir MySonyReader
readerfs MySonyReader
ls MySonyReader
umount MySonyReader

If you get an error about not able to find something, remember you need /usr/local/bin in your PATH to get at FUSE.

I've got a start on a Mac OS X GUI listener application that will listen for the Sony Reader being attached/deetached and bring the filesystem up and down automatically.

I'm working on the bug about ls'ing the dev/fd/10 directory on the Sony Reader. For now I suggest being careful of the /dev directory, ls'ing in there causes the Reader to crash.

If you crash the Reader just umount and then re-run the readerfs after the Sony recovers.

Is there is a way to modify this program in such a way, that it would allow us to use costom fonts in Reader?

Is there is a way to modify this program in such a way, that it would allow us to use costom fonts in Reader?

Doubtful.

I'm pretty sure that will be something someone will have to handle when creating a user friendly Mac/Linux re-flash tool.

Hi, I'm the person behind http://code.google.com/p/prs500fs/ ..
It looks like this is exactly the thing I'm doing (and I was targeting Mac as a first release platform too). Although due to the lack of time I'm still in the "tools" stage - just finished libusb C++ wrappers by today - wanted to start coding prs protocol tomorrow evening.
Any chance to see the source code of scotty1024 filesystem? =)
If so, then perhaps http://code.google.com/p/prs500fs/ is not needed at all..
If not, then we could still benefit by sharing bugs information etc.

Mine is written in C, not C++ and utilizes all my knowledge and 21 years experience in writing portable cross Unix platform code.

I've got the PRS writing protocol code mostly working, a couple more details to iron out and then I'll be posting a new Mac version that can write the Sony.

Source will follow after I get Linux up (my first cut for Debian looks promising).

Mine is written in C, not C++ and utilizes all my knowledge and 21 years experience in writing portable cross Unix platform code.

Sounds cool.


Source will follow after I get Linux up (my first cut for Debian looks promising).

Any approximate timeline available? I.e. I would like to see the sources before shutting down my project.
By the way I incorporated libusb sources directly into the build - i.e. no need for it to be installed, just FUSE. One dependency less for the end-user...

Any approximate timeline available? I.e. I would like to see the sources before shutting down my project.
By the way I incorporated libusb sources directly into the build - i.e. no need for it to be installed, just FUSE. One dependency less for the end-user...

My intent is to produce a portable code base that leverages existing cross platform code. I had originally been working in Objective C producing a Native Mac OS X filesystem when I found Google Mac FUSE via Digg. I figured it was worth it to abandon the native filesystem and gain the portability to other platforms.

I expect to have Mac and Linux done in the next two weeks.

Then comes a Mac GUI App for monitoring inserts/removals to plug/unplug the filesystem and a .deb for Debian. Then a packaged installer with the ability to install Mac FUSE/libusb for the user (for Mac).

Ok.
My plan was to produce working MacOS binary by the end of this week which would include:
* full filesystem operations implemented and tested.
* multiple reader support (in theory, though, since I have just one) - the readers show as different directories in the filesystem root.
* support for main memory, memory stick and SD (being subdirectories of each individual reader directory - I don't have memory stick around though)

Also my intent was to use idle thread within the filesystem binary and/or on-demand mapping rather than a separate listener application. This way the user would "just" mount the filesystem once (perhaps in one of the startup scripts available) and it would handle reader(s) connecting unconnecting on its own.

I guess I'll stick around for some time.

My intent is to produce a portable code base that leverages existing cross platform code. I had originally been working in Objective C producing a Native Mac OS X filesystem when I found Google Mac FUSE via Digg. I figured it was worth it to abandon the native filesystem and gain the portability to other platforms.

I expect to have Mac and Linux done in the next two weeks.

Then comes a Mac GUI App for monitoring inserts/removals to plug/unplug the filesystem and a .deb for Debian. Then a packaged installer with the ability to install Mac FUSE/libusb for the user (for Mac).

Hey Scotty -- How 'bout a PPC version for those of us who can't yet afford an Intel-based Mac? I'd be eager to give it a try!

Xenophon

PPC guy here too! Not sure when I will be able to afford a new Intel-based Mac...

I'll be testing it tonight on a Powerbook 12" G4 1.5GHz (we kept it after upgrading the Wife to an Intel.)

Also, the code has been tested under Leopard on Intel and it works. Just in case anyone was worried about Leopard compatibility.

My wife is handling all the testing. She can break Apple's bug reporting system while filing bugs, she has a real gift for breaking software... :)

The new Sony firmware breaks the existing code.

I have new code up and running (complete with write support and PPC) and will be posting it as soon as testing is completed. Estimate is Sunday/Monday.

Based on feedback from my wife I was already tweaking it to present a virtual root directory that made it easier to navigate to where to drop books and mp3's. I've just had to speed that up.

I'm also working on a folder view that will parse the media XML file(s) and present a foldered view of the content found in those file(s). That will be in the next release.

Great googley moogley.

If your apps don't get ported for Windows, scotty1024, then I just might have to buy a MacPuter. :mad:

when you get around to the GUI I think you deserve the bounty I posted.

The new Sony firmware breaks the existing code.

I have new code up and running (complete with write support and PPC) and will be posting it as soon as testing is completed. Estimate is Sunday/Monday.

Based on feedback from my wife I was already tweaking it to present a virtual root directory that made it easier to navigate to where to drop books and mp3's. I've just had to speed that up.

I'm also working on a folder view that will parse the media XML file(s) and present a foldered view of the content found in those file(s). That will be in the next release.

scotty, all those features are already implemented in the GUI of libprs500, do you really feel the need to duplicate all that code?

Perhaps you might consider a formal collaboration? It sounds like you've each got at least half the problem licked from opposite ends....

Just a thought. :)

I'm not after a bounty, I already married my bounty. :)

I'm doing it because I use Mac's and I've been working on Sony ebook publishing for many years now.

The wife and I are planning on WWDC this year in case anyone wants to meet up there.

Also, if anyone wants to combine and save ~$300 on Apple's buy 5 get 1 free deal on WWDC tickets let me know.

Perhaps you might consider a formal collaboration? It sounds like you've each got at least half the problem licked from opposite ends....

Just a thought. :)

I'm happy to collaborate, all my code is in SVN so it should be really easy to submit patches and if anyone wants to do heavy development I'm happy to give them commit access to the repository.

scotty, all those features are already implemented in the GUI of libprs500, do you really feel the need to duplicate all that code?

I'm not saying anything about your software, I've never seen the GUI working. I never got the Qt stuff working on my Mac. Your command line tools works well and it makes a very handy diagnostic tool.

I don't know if "duplicate" is the correct word here.

But producing a mountable filesystem that slices/dices/frappe's it will make these features available to all developers in their own applications, as well as to your Average Joe using something off the shelf like Word.

And I admit it, I've been "ruined" by compiled languages. I wouldn't have much to contribute to a Python based project except explanations of things I've sussed out of the protocol/Reader files myself.

Well if you have the time, more power to you. I am taking libprs500 towards becoming an ebook library management app as I'm the kind of person that has wall-to-wall collections of pbooks and I want to have equivalent collections of ebooks.

I'm not saying anything about your software, I've never seen the GUI working. I never got the Qt stuff working on my Mac. Your command line tools works well and it makes a very handy diagnostic tool.

I don't know if "duplicate" is the correct word here.

But producing a mountable filesystem that slices/dices/frappe's it will make these features available to all developers in their own applications, as well as to your Average Joe using something off the shelf like Word.

And I admit it, I've been "ruined" by compiled languages. I wouldn't have much to contribute to a Python based project except explanations of things I've sussed out of the protocol/Reader files myself.

Well if you have the time, more power to you. I am taking libprs500 towards becoming an ebook library management app as I'm the kind of person that has wall-to-wall collections of pbooks and I want to have equivalent collections of ebooks.

If your code was in C or C++ I'd be happy to collaborate with you, but it isn't.

I've got many 10's of GB's of ebooks so I'm already into ebook library management. I agree, you want some for sure.

But I think the mountable filesystem will make it easier for people to write a variety of library management systems using their familiar development API's.

Imagine how much easier your Python coding would have been if you could have just read/written files using the standard Python API's. Maybe at some point you'll rip out the USB protocol support and just hop on board the mountable filesystem bus with your project. You'll be free to focus on the library management code and let someone else sweat the USB details as Sony versions the device. :)

An ebook reading device is more than just a filesystem with book files in it. There's metadata as well.

I'm architecting the library so that device interaction is via a plugin. The plugin needs to only provide functions to get the list of books, delete a book and add a book. It takes care of metadata handling internally. If I were to migrate to a filesystem based way of doing it, there'd still be non-trivial code needed for updating the XML databases on the reader. Now that SONY has basically locked out the rest of the filesystem anyway, the justification, imho, for a filesystem view doesn't really exist.

You are correct in that a filesystem interface is the easiest to use for other developers, provided it contains metadata handling as well, however, a command line interface like prs500 is not that much harder.

On a side note, how do you manage your ebook collection?

EDIT: I have no programming language related hangups, though I do find python to be the most efficient (for the developer) language over long term use, so if you ever need help I'll be happy to contribute C code.

OK, here it is, version 0.2 of the mountable Sony Reader Filesystem for Mac OS X 10.4.8.

This is a Universal Binary with support for Intel and Power PC.

This version supports writing to the Reader and a Storage card in the SD slot.

I'm working on MS support, for now, only SD cards work.

This version works with new/old firmware.

You will now see two directories in the "root":
Card
Reader

The Reader "folder" will take you to the Sony Portable Reader's internal data folder "/Data". The Card "folder" will take you to the SD card (hopefully) inserted into your Sony Portable Reader.

Does that mean you can offer some insights as to what changed in the firmware that made the original version stop working, scotty1024?

They locked out access to anything but /Data, /opt0, /opt1, a: and b:.

My wife was already chasing me to "simplify" the filesystem so she could find things she actually cared about. Perhaps someone's wife at Sony was making the same suggestion. :D

They also slightly modified the file format for the media.xml files. Which is a possible issue for prs500 but not for my code (as it doesn't touch those files, yet...)

Tried it - excellent job, scotty.
Minor issue - slow in Finder even when accessing the same folder (I guess it is Finder itself messing with stuff too much, but still).

Thanks.

I'll be turning on the FUSE cache in a few more releases. I want to get the base level fully implemented and solid before I start caching.

I've still got a few more things to suss out in the USB protocol: rename/truncate/filesystem stats.

Did they? Care to elaborate? My basic test of copying a book over and deleting a book worked, but I really haven't had the time to look into it in more detail.


They also slightly modified the file format for the media.xml files. Which is a possible issue for prs500 but not for my code (as it doesn't touch those files, yet...)

couple more reports:
* cannot create directories (at least in /media/books)
* does not like concurrent access with two programs (at least with two Finders, I've never seen "ghost files" in finder before... ;)).

one more thing..
frozen out when I tried to copy 50 megs of scan pdfs onto the SIM.
No idea why, but in an hour it was still "copying" so I killed it off (used Terminal/cp and made sure no other app was interfering (to the best of my knowledge).

@VladSukhoy

I appreciate you taking the time to test and provide all this great feedback!

0.3 will be out in a few days.

Did they? Care to elaborate? My basic test of copying a book over and deleting a book worked, but I really haven't had the time to look into it in more detail.

If I'm not mistaken they've added another namespace:

xmlns="http://xscool.net/xdb/1"

Seems to have been there in the old media.xml as well. Atleast its there in a media.xml on your hdd that's dated Nov. 21.

If I'm not mistaken they've added another namespace:

xmlns="http://xscool.net/xdb/1"

Seems to have been there in the old media.xml as well. Atleast its there in a media.xml on your hdd that's dated Nov. 21.

Maybe its card vs internal media.xml file. I've only really had access to the card files until the last two weeks.

> I appreciate you taking the time to test and provide all this great feedback!
Keep 'em coming ;)
My interest also is to identify potential problems in my own fuse module..
By the way you have a whole bunch of options but not too many docs on them (like "use direct I/O" some kernel magic, unified buffer cache etc.).

Actually at present there are no options in my module...

int main (int argc, char *argv[]) {
externalPath = NULL;
externalPath = alloca(32);
strcpy( externalPath, "b:/"); // hard coded to SD until I get reliable card type detector working

initReaderOps();

fuse_main(argc, argv, &reader_oper, NULL);
#ifdef DEBUG
fprintf( logFile, "Returned from fuse_main\n");
fflush( logFile);
#endif

terminateReaderOps();
}

ok, those were fuse options. I didn't yet get to composing the module itself, just implementing the underlying functionality and regression tests for them.

couple more reports:
* cannot create directories (at least in /media/books)
* does not like concurrent access with two programs (at least with two Finders, I've never seen "ghost files" in finder before... ;)).

Add the directory issue to the firmware update list.

scotty$ mkdir sony/Reader/tmp/test
mkdir: test: Operation not permitted
scotty$ mkdir sony/Card/test
scotty$ ls -dl sony/Card/test
drwxrwxrwx 2 root wheel 0 Feb 13 05:43 sony/Card/test
scotty$ rmdir sony/Card/test

I've tried all the directories on the reader with my debug goodies turned on and the Sony refuses to create directories in any of them. But I can create all the directories I want on the memory card.

I have the old firmware.. Don't want to upgrade unless there really is a reason to.
libprs500 can do it, readerfs cannot (but still can make 'em on SD).

Found it. The internal filesystem requires a trailing / on directories. The SD filesystem doesn't.

OK, here it is, version 0.2 of the mountable Sony Reader Filesystem for Mac OS X 10.4.8.

This is a Universal Binary with support for Intel and Power PC.


...SNIP...

Scotty --

It doesn't appear to be a universal binary! At least, when I try to run it, I get
[Scipio:~/Documents/Downloads] dfsuther% ./readerfs
tcsh: ./readerfs: Bad CPU type in executable.
[Scipio:~/Documents/Downloads] dfsuther%


Of course, I could be misunderstanding the intended usage of the executable. After all, I haven't found any docs on how one is expected to install or use a MacFUSE filesystem... :huh: MacFUSE says that's "up to the filesystem program" (whatever that means).

After poking around a bunch, I guessed that perhaps I should try connecting my reader and firing up the downloaded executable, thus getting the message above.

?help?

Xenophon

I was able to get it to mount on my ICBM; gave it a mountpoint and it worked like a charm.

I had my PRS-500 plugged in on a "good" port already (because I was playing around with biblioskop), so I'm not sure if that had anything to do with my own good luck. I'm also running .2.1 of the core, so that might help.

I'm getting a lot of stalls when I try to navigate too far into the directory structure, hopefully scotty'll be able to iron those out in future releases. He's doing an incredible job with the fuse plugin tho!

-a

...SNIP...

Scotty --

It doesn't appear to be a universal binary!

There are two versions of the code posted here, one is not a Universal Binary and the other one is. I'll give you one guess as to which one I think you are using. :)

You want the 0.2 version.

To date all FUSE filesystem plug-ins follow this basic usage pattern.

Device or service to be mounted needed to inserted or available prior to running the plug in.

You need a folder pre-created to mount them on to.

In Terminal:

mkdir MySonyReader <--- but can be anything you want: Dog, Cat, favorite Rugby Team etc...

Then you run the FUSE plugin naming that folder as the mount point.

In Terminal:

readerfs MySonyReader

Depending on how your path is setup in Terminal you may need to use:

/FolderReaderfsWasUnZippedInto/readerfs MySonyReader

To turn off the plug.

In Terminal:

umount MySonyReader

I've tested the mountable filesystem on Fedora Core 6 and it is working great.

What version of Linux is anyone using here that would want this filesystem? Please let me know so I can package it for you.

There are two versions of the code posted here, one is not a Universal Binary and the other one is. I'll give you one guess as to which one I think you are using. :)

You want the 0.2 version.

To date all FUSE filesystem plug-ins follow this basic usage pattern.
...snip good info on using the plug-in...


Scotty --
I am using the 0.2 version. The problem is that you compiled for the "ppc970" (which is to say the G5). My machine is a G4 (MDD FireWire800, to be precise). So, I get the following:
[Scipio:~/Documents/Downloads] dfsuther% ls -lt ./readerfs
-rwxr-xr-x 1 dfsuther staff 59444 Feb 12 15:24 ./readerfs
[Scipio:~/Documents/Downloads] dfsuther% mkdir readertest
[Scipio:~/Documents/Downloads] dfsuther% ./readerfs readertest
tcsh: ./readerfs: Bad CPU type in executable.
[Scipio:~/Documents/Downloads] dfsuther% file ./readerfs
./readerfs: Mach-O fat file with 2 architectures
./readerfs (for architecture i386): Mach-O executable i386
./readerfs (for architecture ppc970): Mach-O executable ppc
[Scipio:~/Documents/Downloads] dfsuther%


Perhaps you might build with the -mcpu=powerpc instead of -mcpu=970 flag? Or maybe something else rather odd is happening...

Xenophon

I am using kubuntu, so for me a debian package would be great!

Thanks! :)

Scotty --
I am using the 0.2 version. The problem is that you compiled for the "ppc970" (which is to say the G5). My machine is a G4 (MDD FireWire800, to be precise). So, I get the following:
[Scipio:~/Documents/Downloads] dfsuther% ls -lt ./readerfs
-rwxr-xr-x 1 dfsuther staff 59444 Feb 12 15:24 ./readerfs
[Scipio:~/Documents/Downloads] dfsuther% mkdir readertest
[Scipio:~/Documents/Downloads] dfsuther% ./readerfs readertest
tcsh: ./readerfs: Bad CPU type in executable.
[Scipio:~/Documents/Downloads] dfsuther% file ./readerfs
./readerfs: Mach-O fat file with 2 architectures
./readerfs (for architecture i386): Mach-O executable i386
./readerfs (for architecture ppc970): Mach-O executable ppc
[Scipio:~/Documents/Downloads] dfsuther%


Perhaps you might build with the -mcpu=powerpc instead of -mcpu=970 flag? Or maybe something else rather odd is happening...

Xenophon

Now it makes sense. I compiled for the Power PC but accidentally optimized for the G5.

Sorry about that.

OK, this version is not over optimized on the Power PC, it will work on G4's.

It also implements over writing existing files and has the fix for deleting directories.

I've got the automatic card detection working.

The code sorts out how to access MS or SD cards, and if you have no card, doesn't provide the Card folder.

I've got the automatic card detection working.

The code sorts out how to access MS or SD cards, and if you have no card, doesn't provide the Card folder.

Version 0.4 now runs fine on my G4 PowerMac. I have a few questions:

Should I expect to see more than 0K available on either the card or the reader's main memory? (Note that there is actually space available on both.)
Deleting a book from the main memory works fine. Should I expect to be able to copy that book back into main memory? I currently get a "no space available" message when I try. (Likely related to my first question.)
Should I expect a File->GetInfo command to work on any folder on the reader? Current behavior was a very long SPoD, followed by no result.


I'm really psyched by the progress you folks are making hacking stuff for the reader. I eagerly look forward to having multiple non-Sony utilities to choose among for Sony Reader goodness...

Xenophon

I've tested the mountable filesystem on Fedora Core 6 and it is working great.

What version of Linux is anyone using here that would want this filesystem? Please let me know so I can package it for you.

My wife and I have a bunch of SuSE 10.x machines (laptops & servers) so anything that provides 2.6 kernel compatibility should be OK. RPM or source.

Strangely enough, I've found that some files get corrupted while they're being transferred to the reader. I'm attaching a zip file with a document before and after it gets copied using the readerfs.

Any ideas anyone?

These are created using the flatLrf library with some modifications, but they appear kosher to the Sony Connect program on the PC.

-jd

Here is 0.5, it corrects the corruption issue.

I've picked up a sponsor for readerfs and you can expect some exciting Sony Reader developments from them soon.

The collection directory code is nearly complete. While I still haven't cracked how one renames files via USB, it supports moving books between collections and renaming collections. This makes organizing your books a bit easier.

I've picked up a sponsor for readerfs and you can expect some exciting Sony Reader developments from them soon.Is that why you've been so quiet lately, scotty1024? Would you care to elaborate any? :ears:

You go, Scotty!

Is that why you've been so quiet lately, scotty1024? Would you care to elaborate any? :ears:

Not much more I can say at this point but I think there will be more than a few people that will find their tool handy when it hits the market RSN.

I've been busy on several different projects that have chewed up time. My favorite has been the Apple Lisa Emulator. I spent many an hour using a Lisa in my youth... would have been fun to port it to the iLiad, but ain't no future for that vase full of dead flowers.

Not much more I can say at this point but I think there will be more than a few people that will find their tool handy when it hits the market RSN.Okay, I understand. And I know you know where to come for beta testers. :beam:

Color me impressed! I just used your tool to copy my books off my eReader and it worked like a charm. Finder was a bit sluggish, but copying from the command line was reasonably quick. I needed to copy the files because I was rebuilding my pc with connect on it and couldn't find three of the twenty odd books that I had purchased from Sony. Your tool was a life saver (well, maybe not life, but it did save me $20)
thanks
pww

Color me impressed!
...
Finder was a bit sluggish, but copying from the command line was reasonably quick.

I'm glad it worked for you. The Sony Reader is only a USB 1.1 device, USB 1.1 is 40 times slower than USB 2.0. I've generally only ever seen it produce around 500,000 bytes per second. Which sounds like alot until you start slinging around 41MB ebooks like Princess Ai.

The Finder slows down things by constantly looking for the resource fork file (the file that begins with "._") for each file it touches. So each time it opens a file it is actually opening two files. Each time it displays a filename it did two file lookups e.g. it's doing double work.

The commercial application I've been mentioning comes with a graphical browser tool that speeds things up. They say that tool will be made available under GPL.

I hope that I didn't sound like I was complaining. You have done a heck of a job with this.

There is no Windows version, but heck: you've got Sony's CONNECT software on Windows right, you don't need this. :D
Is there any chance of your doing a Windows version, or if not, perhaps you'd like to share the source - I'd be willing to have a shot at creating a suitable device driver.

It's just that the Sony Connect software stinks, and apart from that I'd like the ability to just connect the reader to any old computer and copy over files which I've downloaded. Presently I cannot do this at work, because the office network does not let us install the Connect software.

IMO it's stupid that Sony have not made this device pop-up as an external USB drive.

Is there any chance of your doing a Windows version, or if not, perhaps you'd like to share the source - I'd be willing to have a shot at creating a suitable device driver.


https://libprs500.kovidgoyal.net

Thanks Kovid - I'll have a play with your stuff and see where I get. . .

Is there any chance of your doing a Windows version, or if not, perhaps you'd like to share the source - I'd be willing to have a shot at creating a suitable device driver.

...

IMO it's stupid that Sony have not made this device pop-up as an external USB drive.

The device does not provide block level access to the storage devices, so this isn't a matter of whipping up a USB storage device driver. Rather one must implement a full filesystem for it.

I've written a Windows NT Filesystem before and it's no picnic. In this case it would be even less of a picnic since the Sony Reader exports a VFS style RPC-over-USB model and that is about 180 degrees out of phase with Windows.

Also, as a memory card reader/writer the Sony Reader makes a pretty poor one since it only supports USB 1.1 and manages to slow that down to about 1/3rd performance. If you need to copy many books, MP3's, pictures onto a memory card for the Sony you'll get much more done quickly via a good quality USB 2.0 memory card device.

Demand for this filesystem has been very low on the Mac, nearly non-existent for Linux and I'd have to think even lower than that for Windows.

Personally I appreciate the Sony Reader not supporting the USB Mass Storage Profile. In Fortune 500 environments UMSP is rapidly becoming Public Enemy Number One and I'd rather have my Sony with me than checked with security at the front desk (or out baking in the car.)

Also, as a memory card reader/writer the Sony Reader makes a pretty poor one since it only supports USB 1.1 and manages to slow that down to about 1/3rd performance. If you need to copy many books, MP3's, pictures onto a memory card for the Sony you'll get much more done quickly via a good quality USB 2.0 memory card device.

Demand for this filesystem has been very low on the Mac, nearly non-existent for Linux and I'd have to think even lower than that for Windows.


Scotty:

I'd make more use of it if I could do a couple more things via the Finder:

Create collections by making a new folder in the Collections structure
Transparently move content from card to internal memory, and vice versa
Set document attributes in the GetInfo window for the document (or somewhere)
Ummm.... I had some more in mind when I started writing this list, but I got interrupted and forgot 'em... :embarasse

The commercial outfit informed me yesterday that they will be releasing their GPL GUI tool this week.

There is some hope for this tool to fix some of the issues you raise.

I have newer code working that does the collections trick and implements renaming/moving files around via manipulation of the XML files. I'm still working to stabilize its thread safety in between slugging away at the LRS->LRF compiler project.

The commercial outfit informed me yesterday that they will be releasing their GPL GUI tool this week.That'll be a frontpage worthy event. :beam:

Any more word, Scotty? We're running low on week .... :wink:

Nope, nada.

Nope, nada.

:bigcry: :bigcry: :bigcry: :bigcry:

So... scotty1024 :whip: better lean on them to get to work.. :D

Xenophon

Here it is folks: http://labs.docudesk.com/

Downloaded, installed, tried... Sweeeeet! :D

Xenophon

P.S. After I've played around with it a bit, I'll have lots and lots of questions. Look great at first blush, though.

Very very very cool! This thing rocks. Works perfect and I was FINALLY able to delete the book samples that came with the reader. The drag-and-drop works perfectly too.

This is awesome Scotty. You rock!

Now for lots and lots of questions (from the 'give them an inch and they want a mile' department):

Is there a way to traverse the folder structure on the PRS500? I have a bunch of sub-directories, but was unable to open them.
Any support for viewing or editing metadata?
What about collections? It'd be beyond cool to be able to create, move and re-order books inside collections via your tool.
...and what about Naomi?


When it comes to adding and removing files from the top level of the card and the internal memory, everything works really really well.

I tried moving a folder, however, and got told "File already exists on Reader" and asked whether I wanted to over-write. Hmmmm...

Very very very cool! This thing rocks. Works perfect and I was FINALLY able to delete the book samples that came with the reader. The drag-and-drop works perfectly too.

This is awesome Scotty. You rock!

Why didn't you just delete them with the Connect software?

I don't have a Mac, but I would still love to see a screenshot or two. Anyone? :)

I don't have a Mac, but I would still love to see a screenshot or two. Anyone? :)

Here you go. Enjoy.

Uh folks, I don't work for Docudesk. They wrote the graphical thingy on top of the readerfs.

Keep an eye on their site. If you liked the browser you are likely to like their next Sony Reader product even more...

They're nice folks and cruise MR. If you post to them you may draw them out of lurking to discuss what they are up to.

Diablo wrote: Why didn't you just delete them with the Connect software?

Prob'ly because he's a Mac user like me, who can't run the *&^%*&^%$^%$# connect software because Sony doesn't realize what a large fraction of their early adopters are Mac users. :angry: (Angry at Sony, not at Diablo)

Diablo wrote:

Prob'ly because he's a Mac user like me, who can't run the *&^%*&^%$^%$# connect software because Sony doesn't realize what a large fraction of their early adopters are Mac users. :angry: (Angry at Sony, not at Diablo)

Sorry, forgot that Connect doesn't run on a Mac. :shy:

Here you go. Enjoy.
Thanks ;)

Uh folks, I don't work for Docudesk. They wrote the graphical thingy on top of the readerfs.

Keep an eye on their site. If you liked the browser you are likely to like their next Sony Reader product even more...

They're nice folks and cruise MR. If you post to them you may draw them out of lurking to discuss what they are up to.
So what is their next Sony Reader product? Ifs there going to be a Windows version?

Why didn't you just delete them with the Connect software?

I'm on an older Mac (non-intel) so I have no way of using the Connect software. :uhoh2:

I thought Virtual PC worked?

Hi Xenophon,

With regards to traversing the folder structure, is creating nested folders something you can do with the Windows Connect Reader software or the PRS500 itself or is this specific to the readerfs implementation?

Hi Xenophon,

With regards to traversing the folder structure, is creating nested folders something you can do with the Windows Connect Reader software or the PRS500 itself or is this specific to the readerfs implementation?

Welcome aboard Mohan!

So what is their next Sony Reader product? Ifs there going to be a Windows version?
Here at Docudesk, all of our developers use the PRS-500 as they were issued as gifts from the company. The lack of Mac support was obviously a big issue as well as the inability to convert PDF into reflowable/resizable content for the reader. We created the PRS Browser wrapper for ReaderFS for our own convenience and to further the cause of e-paper devices. Our upcoming product is a new version of our existing PDF converter product which creates dynamic BBeB/Lrf output. This new version is also being developed for OS X. Since OS X uses PDFs natively in the print path, we include a workflow for sending printer output directly to the converter, effectively creating an BBeB print driver. We will be posting a technology preview of the Mac and Win32 versions on our Docudesk Labs site later this week. For this preview version, the Lrf output will work indefinitely (past the normal trial period) without having to purchase the software.

Hello all,

There was a message a while back about readerfs working on a linux distro....

Is there a linux binary, debian package, or a source repository available?

Not looking for a gui, just the command-line mount.

I'm using:
kernel 2.6.17
debian testing

I already have fuse installed (libfuse2 2.5.3-4.1) for encfs,
would that work with this?

Thanks,
Lee

Hi Xenophon,

With regards to traversing the folder structure, is creating nested folders something you can do with the Windows Connect Reader software or the PRS500 itself or is this specific to the readerfs implementation?

Well... I've been managing files on the reader using a SD card and a card-reader hanging off my Mac. A result of this is that I have my books organized in folders by (primary) author, with all of these living inside a folder named 'By Author'.

When I just use the raw FUSE-based filesystem that Scotty wrote, I can copy folders (and their nested contents) smoothly. When I do this with your tool, it doesn't work.

The PRS500 finds the files just fine, and displays them in the usual fashion. I'd sure like to be able to use your nice GUI-based tool to manage my books in a similar fashion. I rather expected to be able to drag-n-drop my 'By Authors' folder and have all its recursive contents copied to the PRS500.

Xenophon

Here at Docudesk, all of our developers use the PRS-500 as they were issued as gifts from the company. The lack of Mac support was obviously a big issue as well as the inability to convert PDF into reflowable/resizable content for the reader. We created the PRS Browser wrapper for ReaderFS for our own convenience and to further the cause of e-paper devices. Our upcoming product is a new version of our existing PDF converter product which creates dynamic BBeB/Lrf output. This new version is also being developed for OS X. Since OS X uses PDFs natively in the print path, we include a workflow for sending printer output directly to the converter, effectively creating an BBeB print driver. We will be posting a technology preview of the Mac and Win32 versions on our Docudesk Labs site later this week. For this preview version, the Lrf output will work indefinitely (past the normal trial period) without having to purchase the software.

That's super news! Especially the part about the lrf output working indefinitely without purchase. :) :) Emphasis in the quote is mine.

Here at Docudesk, all of our developers use the PRS-500 as they were issued as gifts from the company. The lack of Mac support was obviously a big issue as well as the inability to convert PDF into reflowable/resizable content for the reader. We created the PRS Browser wrapper for ReaderFS for our own convenience and to further the cause of e-paper devices. Our upcoming product is a new version of our existing PDF converter product which creates dynamic BBeB/Lrf output. This new version is also being developed for OS X. Since OS X uses PDFs natively in the print path, we include a workflow for sending printer output directly to the converter, effectively creating an BBeB print driver. We will be posting a technology preview of the Mac and Win32 versions on our Docudesk Labs site later this week. For this preview version, the Lrf output will work indefinitely (past the normal trial period) without having to purchase the software.
That is awesome. I look forward to trying it out. And having the LRF output work indefinately is a really nice bonus. Thank you in advance.

Jon

I thought Virtual PC worked?
You still need a licence for Windows to install it to Virtual PC. And it is not supposed to be an OEM licence.
$250 for a legal way to delete a few files from a simple device ...

You still need a licence for Windows to install it to Virtual PC. And it is not supposed to be an OEM licence.
$250 for a legal way to delete a few files from a simple device ...

Virtual PC is available with a bundled XP but yeah, a bit pricey for capping a couple of files. :-)

I'm using:
kernel 2.6.17
debian testing

Here is a readerfs compiled for Feisty Fawn. Let me know if it works for you.

1. Plug in your PRS-500
2. readerfs <name of directory to mount on>
3. ls a/Reader (or whatever)
4. umount <name of directory to mount on>

Here is a readerfs compiled for Feisty Fawn. Let me know if it works for you.

1. Plug in your PRS-500
2. readerfs <name of directory to mount on>
3. ls a/Reader (or whatever)
4. umount <name of directory to mount on>

I'm still waiting for the reader stork to deliver, but it should be here in a day or so.
I just wanted to get the software loaded up and running before the great day.

I checked out the binary with ldd and all seems well.

When I first ran it (with no options) it complained that my installed libfuse wasn't
the right version, so I updated to 2.6 and it no longer complains.
(other than telling me I forgot the mount point, which is true).

I'll let ya know how she flies when my baby arrives.

Thanks,
Lee

Here is a readerfs compiled for Feisty Fawn. Let me know if it works for you.
Works here on Feisty :D Thanks!!

EDIT: The issue discussed in this post is not related to Docudesk or readerfs. It was bad LRF generation on my part (now fixed) and never had anything to do with Docudesk/readerfs.

There was some previous discussion about Metadata, and I think this may be a real problem.

I generated two LRF files with TOCs in the Menu. Just to make sure I'm clear, when you've selected a book, it's entry #5 "Table of Contents" which you can select by pressing 5 on the Reader. So I'm not talking a TOC page, but the TOC menu. :)

I used Docudesk on one LRF, and after I unmounted/restarted the Reader, it spun for a VERY LONG TIME... generating new metadata I assume. When I went to my new LRF, selected #5 - "Table of Contents" the Reader locked up for over a minute! Once it came back, I was able to select an item. However, if I returned to the TOC Menu, I was dead again for a minute or two. This basically rendered the TOC unusable.

With my second LRF, I used the Connect Software to transfer. Selecting the TOC here had about a 5 second delay, even though it was about the same size as the other LRF. I've generated a few other LRFs with 25 or more TOC entries, and these also worked fine when using Connect to transfer.

Even using Connect to re-transfer the "bad" LRF doesn't help. It looks like the Reader re-uses the Metadata, and it makes determining the problem all that much harder (is it that particular file? is it the metadata? etc.)

The only solution I can think of is reformatting the Reader and starting over (how?). Or maybe I can delete one of the two media.xml files, and the reader will be forced to use the other (assuming the one to delete is in /tmp/database/cache).

Any thoughts?

-Pie

Use the libprs500 gui to delete files from the reader. It automatically removes the corresponding entry from the correct XML database.

Let me be a bit more specific here.

(1) Which file contains the metatdata that the Reader Software uses?

(2) What are the tags that begin and end a section relating to a specific book?

-Pie

That is awesome. I look forward to trying it out. And having the LRF output work indefinately is a really nice bonus. Thank you in advance.

Jon
PDF to BBeB/Lrf utility for Mac and Windows, as promised with unlimited PDF-Lrf conversions:
http://labs.docudesk.com/latest-technologies/2007/5/8/create-reflowable-content-for-the-sony-reader-with-deskunpdf.html

enjoy!

PDF to BBeB/Lrf utility for Mac and Windows, as promised with unlimited PDF-Lrf conversions:
http://labs.docudesk.com/latest-technologies/2007/5/8/create-reflowable-content-for-the-sony-reader-with-deskunpdf.html

enjoy!

Great work guys! Thanks!

I have completely avoided PDFs because they suck beyond measure on the Reader. This opens up a whole new realm of possibilities!

-Pie

Hey Scotty:

Does your mountable file system give access to the meta-data for books? Either directly, or via the xml file that the reader keeps on the card/in memory? It'd be cool to be able to update meta-data about books while writing them onto the reader.
(Yes, I know... libprs500 does that now in an integrated fashion. I'm looking for still other ways of doing it.)

Hey Scotty:

Does your mountable file system give access to the meta-data for books? Either directly, or via the xml file that the reader keeps on the card/in memory? It'd be cool to be able to update meta-data about books while writing them onto the reader.
(Yes, I know... libprs500 does that now in an integrated fashion. I'm looking for still other ways of doing it.)

May I ask why?

There was some previous discussion about Metadata, and I think this may be a real problem.


Update on this issue.

I checked the media.xml file in both the database/cache and tmp/database/cache directories, and there are no references to my problematic book.

I re-generated the lrf, creating a 27-entry TOC. Transferred with Connect software, and STILL have the 30-40 second load problem (after pressing "5" for TOC Menu).

Unless there is another location for metadata, I don't think the problem is related to direct transferring via "readerfs" or the Mac GUI version. It's this particular book. Very much so, since every other LRF I genrerate, many with 30 TOC entries, load in 5 seconds.

Does your mountable file system give access to the meta-data for books?

Xenophon, as you can see from the above, it indeed does give access to the metadata. It's in two locations:

<mountpoint>/Reader/database/cache/media.xml
and
<mountpoint>/Reader/tmp/database/cache/media.xml


In the "tmp" directory, I still have references to the original "excerpt" ebooks that came with my Reader -- long since deleted. And looking at libprs500 to verify my suspicions, it seems like that one isn't used. The libprs500 only refers to "Reader/database/cache/media.xml" in its code.

Generating the Metadata is another issue all together, and scotty's program alone doesn't do this... so you've only won half the battle going that route.

-Pie

There can be various sources for slowdowns in an LRF file. Too many TextBlocks, a single very large Page element, ...

Ah! Good info!

Is there a rule of thumb about when to use a new page? I go one page structure per chapter.

-Pie

you'll need to experiment
add textblocks to a page and see where the slowdown starts

you'll need to experiment
add textblocks to a page and see where the slowdown starts

All right! I was carelessly generating a TextBlock per paragraph. Now I only generate on demand, and this made a HUGE difference. The Table of Content Menu loads instantly now. Not 5 seconds, not 2 seconds, but the instant you hit the "5" button.

Thank you very much for pointing me in the right direction. I'm very happy with this new update!

http://www.mobileread.com/forums/showthread.php?t=10752

And this sounds the all clear for using Docudesk / readerfs to transfer files. They had nothing to do with my slow LRF.

-Pie

I know this is an old thread, however can someone tell me where to find the latest (or last) version of this FUSE filesystem is to be found?
Sounds like a terrific idea.. :)

PDF to BBeB/Lrf utility for Mac and Windows, as promised with unlimited PDF-Lrf conversions:
http://labs.docudesk.com/latest-technologies/2007/5/8/create-reflowable-content-for-the-sony-reader-with-deskunpdf.html

enjoy!

Hello ... one of the version has the unlimited LRF conversions? Is it pro?