first, I tried to repair the filesystem using fsck.vfat (part of the dosfstools suite), without any success. so I finally just made a plain dump using dd, planning to work on the dump rather than on the real SD card.

so I made my way to google and found Cédric Blancher’s wiki entry about recovering digital photos. lots of very useful information what to do:

1. examine dd-image with hexedit

the starting signature for a JPEG file is 0xFFD8, the corresponding end-signature is 0xFFD9. so just looking for those chars gives you the hex-offsets of the start and end of a picture:

hexedit image.dd
[...]
0385C000   FF D8 FF E1  79 FE 45 78  69 66 00 00  49 49 2A 00  ....y.Exif..II*.
0385C010   08 00 00 00  0D 00 0F 01  02 00 0A 00  00 00 AA 00  ................
0385C020   00 00 10 01  02 00 09 00  00 00 B4 00  00 00 12 01  ................
0385C030   03 00 01 00  00 00 08 00  00 00 1A 01  05 00 01 00  ................
0385C040   00 00 BE 00  00 00 1B 01  05 00 01 00  00 00 C6 00  ................
0385C050   00 00 28 01  03 00 01 00  00 00 02 00  00 00 31 01  ..(...........1.
0385C060   02 00 0A 00  00 00 CE 00  00 00 32 01  02 00 14 00  ..........2.....
0385C070   00 00 D8 00  00 00 13 02  03 00 01 00  00 00 02 00  ................
0385C080   00 00 69 87  04 00 01 00  00 00 7C 02  00 00 A5 C4  ..i.......|.....
0385C090   07 00 D0 00  00 00 EC 00  00 00 D2 C6  07 00 40 00  ..............@.
0385C0A0   00 00 BC 01  00 00 D3 C6  07 00 80 00  00 00 FC 01  ................
0385C0B0   00 00 20 28  00 00 50 61  6E 61 73 6F  6E 69 63 00  .. (..Panasonic.
0385C0C0   44 4D 43 2D  46 5A 32 38  00 00 B4 00  00 00 01 00  DMC-FZ28........
[...]

so the beginning of the above file is at offset 0x0385C000. unfortunately, there are some problems…

first, the end-marker proved to be unreliable. to solve this, I just had a look at the size other pictures taken with this camera and discovered that the maximum filesize is roughly 5.1 MB. so just dumping 5.5 MB from the starting marker should make its job…
second, the SD card contained a lot more JPGs than just those taken with this camera. so I decided to have a look at the EXIF data that follows the header right away and contains the name of the cam in plain text: “DMC-FZ28”. so just look for that string and then find the last occurence of the start-marker before…
last, it is a pity job to extract the offsets manually and is at maximum to be meant for testing. to do such a test-extraction, you just need the offset and the size of the chunk you want to cut out (both values converted to the block-size used with dd) . so here’s how to do that manually (note that bash can convert from hex to decimal by using $((...))):

BS=1024
dd if=image.dd of=$(date +%s).jpg bs=${BS} skip=$((0x0385C000/${BS})) count=$((5529600/${BS}))

2. extract offsets with hexdump

since I didn’t want to do this for all pictures manually, I used hexdump and grep to go fishing for the offset-values. as mentioned above, I looked for the string identifying the camera model. figure out how much additional lines you need for the starting-marker (in this case it’s 12, hence the grep -B 12):

hexdump -C image.dd  | grep -B 12 FZ28 > markers

in my case the starting markers were always at the beginning of a line, so extracting the offsets from the above file just works like this:

grep '  ff d8 ' markers | cut -c 1-8 > offsets

3. extract JPEGs using dd and the gathered offsets

for better readability, let’s define a simple function to dump the JPEGs:

dumpjpg() {
    BS=1024
    FNAME=${1}
    echo "dumping to ${FNAME}"
    dd if=../TRIFOO.dd of=${FNAME}.jpg bs=${BS} skip=$((${1}/${BS})) count=$((5529600/${BS})) status=noxfer
}

then, do the actual work:

for offset in $(cat offsets) ; do
    dumpjpg 0x${offset}
done

I love Linux

Having succeeded in recovering approximately 100 files this way, I just discovered (on ubuntugeek.org) the existance of special tools that do exactly the same:

foremost -q -t jpg -i image.dd

we need a more recent version of rails and rubygems than those shipped with lenny, so first add the backports-repository to your sources.list:

deb http://www.backports.org/debian lenny-backports main contrib non-free

then, update your package list:

sudo apt-get update

and install the above mentioned packages

sudo aptitude -t lenny-backports install rails rubygems

in addition, librmagick and ruby’s mysql bindings are required:

sudo aptitude install librmagick-ruby1.8 libmysql-ruby1.8

next, we need an additional gem called rack which is not available as a debian package in the required version (has to be 1.0.1 sharp). thus, we install it locally in a separate directory below /opt/. so lets create a directory for the gems, set the path accordingly and install the gem:

sudo mkdir /opt/ruby_gems
sudo chown $(whoami): /opt/ruby_gems
export GEM_HOME=/opt/ruby_gems
gem install rack -v=1.0.1

create a database and a corresponding user in mysql:

CREATE DATABASE redmine CHARACTER SET utf8;
CREATE USER 'redmine'@'localhost' IDENTIFIED BY 'my_password';
GRANT ALL PRIVILEGES ON redmine.* TO 'redmine'@'localhost';

of course we need to download redmine itself, which can be found on rubyforge.org. we’ll put it somewhere in /opt/ as well, so:

tar xzf redmine-1.0.0.tar.gz
sudo mv redmine-1.0.0 /opt/redmine
cd /opt/redmine/config
cp -v database.yml.example database.yml
cp -v email.yml.example email.yml
vim database.yml
vim email.yml
rake generate_session_store
RAILS_ENV=production rake db:migrate
RAILS_ENV=production rake redmine:load_default_data
sudo chown -R root.root .
sudo chown -R www-data.www-data files log tmp public/plugin_assets
sudo chown -R root.root /opt/ruby_gems
cd /var/www
sudo ln -s /opt/redmine/public/ redmine

make sure the apache modules mod_rewrite and mod_passenger are enabled, then edit your apache virtualhost configuration and add the following section:

    # <redmine stuff>
    <Directory /var/www/redmine>
        RailsEnv production
        RailsBaseURI /redmine
        Options -MultiViews
        AllowOverride all
    </Directory>
    # </redmine stuff>

since we have installed the rack-gem in a non-standard location, we have to pass this information along to the ruby-process. in an interactive shell-session, this can be done by simply exporting the relevant variable(s). since our ruby is called by apache, we have to append this into /etc/apache/envvars (see stackoverflow #79474 and blog-entry 223 on phusion for more information):

sudo -s -H
echo 'export GEM_HOME=/opt/ruby_gems' >> /etc/apache/envvars
exit

now the last obstacle is the way phusion passenger handles privileges for the script to call: it runs a Rails application as the owner of environment.rb (see rubyforge issue #23105 for details), so we need to do a final chown on that file to make sure redmine has write-access to the files owned by www-data (this is certainly a security-issue, so creating a separate user for redmine instead of using www-data is by far the more elegant solution…)

sudo chown www-data.www-data config/environment.rb

that should be all, now restart apache and navigate to your redmine-installation:

sudo apache2ctl graceful

This can be fixed by editing (or creating) the system-wide gimprc file, which is located in \Data\settings\ …

First, I tried to use the windows-style %APPDATA% variable, but GIMP does not interpret it correctly. Digging a bit in the web revealed the way how to do it, they have to be used in shell-style including curly brackets like this:

(temp-path "${APPDATA}\\gimp-2.6")
(swap-path "${APPDATA}\\gimp-2.6")
 
(undo-size 512M)

-> open windows firewall, tcp port 6000
-> adjust the Xming startup command, include a full path for the logfile, e.g. “C:\Temp\Xming.log” instead of a filename only

aptitude search "?obsolete"

or as a shorthand:

aptitude search "~o"

See the aptitude Reference Guide for more information.

user_pref("calendar.debug.log", true);
user_pref("calendar.debug.log.verbose", true);

UPDATE:

http://releases.mozilla.org/pub/mozilla.org/calendar/lightning/releases/1.0b1/contrib/linux-x86_64/