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 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:
- DON'T PANIC
- If fusermount -u say that the device is busy, use ps
to check that there's no process running inside the FUSE file system
- 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.