FUR

• What it is?
• What it does?
• What does it need?
• Where can i find it?
• How do i make it work?
• What work now?
• What does not?
• How can i contact you?
• Why should i?
• And who are you anyway?

NEWS

5/06/2006 FUR letargic but not dead: fixed a bug that prevented it from renaming a file overwriting an existing destination (Thanks to Clemens R. for the report!). Here you go...

?/05/2006 Fixed a couple of broken links and re-tarred the package of FUR-0.4.0.tar.gz (which was incorrectly compressed with bzip2...). I apologize for every inconvenient this may have caused to you.

28/04/2006 SRPMS available for FUR! Genix, which i thank also for his precious feedback and help in the bug fixing on FUR as well as for a patch to enhance the configure script (not yet included, sorry... :-/ ) has made available source packages for the ALT linux distribution:  the page is in russian, but links are in plain English; it's likely that the synce library should be patched and compiled manually and that some incompatibilities could arise on non-ALT linux systems, notheless maybe they could be useful for people on RPM based system.

22/04/2006 A new filesystem for browsing a Window CE device on linux called SynCE FS has been released by Laurent Vivier: the developer is spending a consistent effort to enhance the program, which might be worth checking: to get the latest news/releases, search "SynCE FS" in the SynCE-devel mailing list on sourceforge.

?/03/2006 The bug revealed itself as a strange behaviour of the device (which contained 2 files with names different only in case in the /windows directory). Im still puzzled if the crash is to be considered a bug or not (afaik, windowce uses vfat filesystem, which doens't distinguish between case in file names...). The problem has been solved for Lazlo commenting the assert at line 485 of fur_utils.c (which probably will be substituted with a warning in the next release).

24/03/2006 Discovered a bug which seem to crash FUR on some circumstances when reading the content of a directory (thanks to Laszlo for the report): im quite overloaded by work (as can be seen from the last release...) but i will work on it as soon as i will have more informations (and enough time).

27/02/2006 Received some patch to enhance the configuration script and enable a correct installation of FUR (Thank you Genix!): the files will be included in the next release.

6/02/2006 Added a proc like directory  into FUR: there are 2 files for now: power_status and regkeys; do they need explanations? I think not... :-)

The filesystem seems stable, but proc is not: don't expect it to work perfectly.

The attributes can be read as raw data, don't expect fancy printing of numbers or endianess connection, i don't know if it will ever happen (i like them that way, but im open for suggestion) and... take a book before reading into the regkeys directory: you will need it while waiting ;-)

Write in the procis not implemented: i don't know how much is needed and i think i will concentrate on other things in the future (like putting the correct time attribute on the files).

The file is here.

26/01/2006 Implemented a small patch to librapi (which you can find here): it doesn't change the behavior of the library
other than adding the CeSetFilePointer and CeSetEndOfFile API. Now that the whole crock which emulated them in FUR is
gone, FUR seems to be stable!

You can find the new version here: i used it quite for a while without noticing crash/bugs of any kind, if you find some, please,
tell me.

Of course to use this version you have to install the patch: enter the synce-librapi2-0.9.1 directory and execute:

    patch -p1 <librapi.patch

Recompile and reinstall (this will not change the behaviour of the library in other applications) and you should be ready to
run the flaming new FUR-0.3.0!

As far as i know, FUR is working decently now tough many features are still missing: let me know if (how much :-) ) im wrong!

25/01/2006 first milestone reached: FUR compiled and executed (not mounted) on FUR!

20/01/2006 Good news: i discovered other bugs (-> hopefully i will be able to correct them). Bad news: i discovered other bugs.
The seek/truncate workaround are driving me mad. Week end will be likely dedicated to make FUR a bit more stable. Stay tuned.

18/01/2006 Fur-0.2.2 released! You can find it here: some bugs removed and a (what seem a) working seek function implemented.

Truncate doesn't  still work, but  the fs should be more stable. Multi threading not tested (but may work also).

I also have added a small Change log here.

What it is?

FUR is a application that let the user mount a Windows CE based device on your Linux file system: it uses the brilliant FUSE (acronym of File system in UserSpacE of Miklos Szeredi)  which you can find here and the great librapi2 of the Synce Project, a unix implementation of the RAPI protocol (that your device use to communicate with your other operating $system ) which you can find here, along with other very nice tools.

What it does?

You execute it with proper arguments, then (if everything goes fine) the entire file system of your (previously connected) handheld will appear automagically mounted like a regular Linux file system where you will be able to copy, move read and write data with your favorite programs.

What does it need?

FUR need at least a fuse distribution version 2.4.2 and synce-librapi2 version 0.9.1 tough i cannot guarantee it will not work with older versions of both software.

Where can i find it?

Try here... (latest version)

How do i make it work?

I will not go inside the details of installation and configuration of FUSE and Synce on your machine (you can find all the instructions you may need here and here): once you have the first working (i.e. you can test it compiling and running one of the example programs included with the tgz, or you can download one of the _very_ fine projects you can find linked to the FUSE homepage (preferably not this...)) and a connection to your handheld (use the command synce-pls or pls to check if it's working), read this license and, if you agree, configure and install fur.

I apologize for quality of the configuration tool: this is my first try,one with bells and whistles will be available sooner or later, but until then there's only a small configure which should work.

After the ./configure step, simply issue:

./make 

and if everything goes well a small binary named Fur will appear in the directory. Do you want to try it, won't you? Execute:

./Fur destination_directory

and your device fs should appear there.

When you want to unmount it simply issue:

fusermount -u destination_directory

If something goes wrong and you can't unmount the file system, in order:

1. DON'T PANIC
2. If fusermount -u say that the device is busy, use ps to check that there's no process running inside the FUSE file system
3. If everything fails, try killall -9 Fur and then again retry step 2.

What work now? (outdated)

Fist of all, understand that FUR is Beta software, still in development, actually is a week end hack: it is not stable, optimized, nice, user friendly or anything... This does not mean it will not become such in the (maybe near) future, but don't expect it to be fast or rock solid; i actually use  it and it never did anything so wrong that could not be undone with a couple of kill -9 and  a fusermount -u plus remounting but i didn't test it thoroughly and i cannot guarantee it will not do something very NASTY to your universe of choice: make a backup of your handheld device before using it, and have a backup of your important data on your computer to, which is always a Good Idea, and keep in mind the license.

5/1/2006

• All read operations seem pretty stable: as long as you limit yourself to them you should be safe  (but  please  re-read the disclaimer and the previous paragraph again...), which means you can change and list directories, and read sequentially files (means you can copy them around without problem).
• Rename/Move work.
  
• Reading files in random access fashion also works, but due to the lack of a Seek api in the librapi2, the file pointer is moved with a combination of fake reads, open and close. Go figure.
• The minimum set of attributes to make the fs usable work: file size, permissions and owner, tough permissions are actually not read from your device but assumed rw for every file (which is plain wrong for system files).
  
• Mkdir and mknod seem to work.
• Hic sunt leones: write almost work, with the same remarks for the read operation (sequential work fine, random access seem to) but there are unresolved issues (which i hope to handle soon), if you limit writing to file copying, should work decently tough.
  

What does not? (outdated)

5/1/2005

• Not very stable, particularly if used concurrently by different processes (but should be usable).
• Not well tested.
  
• The source is horrible(Tm).
• The implementation is more involved than it should.
  
• Lack documentation.
  
• Not even remotely optimized.
• Configuration tools deficient.
  
• Random access I/O is anti-optimized. 
• The resource locking system (e.g. to prevent different processes to write on the same file)  is only roughly implemented (there's a lot to be done).
• Total absence of a caching system of some sort (which i hope to implement, sooner or later).
• Some errors are to obscure (and maybe not well implemented).
• Some attributes (e.g. ctime) are not implemented (the needed function in the librapi2 library is not yet implemented).
• No UID/GID check: this is not a security issue: only the user that invoke the dccm demon can access the filesystem, but other users should be able to see some kind of error message (which i will implement soon).
• Lot of other things i have forgot now.
• The log reporting sucks.
  

How can i contact you?

You can send me a mail  (riccardo A_t_  infis Dot univ D0t trieste d0t it): please, specify something like "FUR:" or "fur:" in the title, so i can tell my spam eater not to trash it.

Why should i?

I.e. to tell me that you use FUR and you like it (or you did not): i can't promise anything, but the more will i feel that this project is useful to someone and the more i will feel like to fix bugs or add features/documentation: consider that FUR is yet good enough for me to use  and as long as i don't receive feedback, my interest in this project is likely to decrease.

Flames go to /dev/null.

Another good reason is to inform me about a bug, but before you send me a report, first check that:

• you have read ALL the documentation (this page...): c'mon, it's not that much!
  
• you have the right versions of the librapi2 and fuse.
• both work.
• You have the latest version of FUR.
• Your problem is not yet listed in the bug list (ok... when i have one...).
  

The best way to inform me about a bug compile it with the -g option and send me a core dump (you can obtain one executing ulimit -c unlimited before mounting FUR, the core will appear in the directory where FUR was mounted, after a crash) and a description of the problem.
 
I don't think that from the very moment this project will hit the web i will start receiving as much email as Madonna, but still i cannot guarantee that i will be able to answer to anyone:  i will try tough, and if you don't receive a answer, don't take it personal: it could be that the question is out of context ("How do i install synce/fuse/linux?", "Why every time i mount  FUR i feel a sharp pain in the  right  eye?" and the like) or simply that i'm busy.

And who are you anyway?

My name is Riccardo Di Meo, i actually work for the ICTP and more precisely in the Egrid project   as programmer. I live in Trieste, a nice city in the NE of Italy. Almost all interest i have are related to computers (and programming mainly) or swimming, and this  is the first project i  submit to the the world.