Notices

Estel's thread on automated uploading of camera images caused me to look into use of inotify to monitor the camera storage and trigger an upload.

This led me to multiple ways of using inotify on the N900; within the maemo repositories we already have inotify-tools, which provides inotifywait, useful for manual command-line work. However, rather than reinvent the wheel, debian provides inoticoming for monitoring a given 'incoming' directory and running a command when new files arrive. It might be nice to see this packaged for maemo.

So, then I went digging a little further and found incron, which provides a daemon to allow us to monitor multiple files or directories for filesystem events, with a crontab-like interface. This would seem to be ideal for handling photo uploads with or without an SD card present, and also perhaps for a range of other automated backup/file transfer applications. Hence this new thread; I want to discuss getting incron working on the N900 and the possible use cases for doing so. As it stands, incron is not in the maemo repositories, but the squeeze version installs happily provided that you first satisfy its dependency on 'adduser'.

Steps to install incron:

- install adduser, using apt-get or your favourite package manager
- download the incron deb with wget, install with it dpkg -i
- edit /etc/incron.allow to include user, root, or both
- create a startup script as /etc/event.d/incron

- now try starting incron via event.d with "start incron"
- reboot and verify that incrond is running as expected
- when it is, edit your incrontab to suit your use case

So, if our use case is that of uploading photos, we can do something like

which will upload photos via WebDAV any time a new image is taken, with or without an SD card present. I can see a few other possible use cases, too: the arrival of a new e-mail in Modest's sent / drafts folder could (in theory) be copied to an IMAP server (that'll require the latest version of curl), and I'd welcome other possible use cases.

@magick777,

Just wanted to say thanks. This is seriously sweet stuff.

Use case 2: post-processing camera images with ImageMagick

For some reason let's say we want smaller images, whether that's for web or e-mail use or whatever. Perhaps we just want to save on our upload bandwidth when we backup / publish our images. Anyway, we can tell incron to call ImageMagick on any newly-created photo, placing the smaller image under /media/mmc1/vga/ (which we've created manually beforehand)

Then we (optionally) trigger an upload of the VGA-resolution image when it arrives in the ImageMagick output dir (second line). Or we could do whatever else with it...if we install 'mailcmd' then we have a command-line approach to sending e-mail from the default account in modest.

It takes typically 12-15 seconds to shrink the photo, attach it to an e-mail and dump it in Modest's outbox for sending.

Nice thread.

What about when you're offline? How to queue taken photos and upload only when connected through WiFi?

There's a few ways to do that, none of them directly related to inotify.

Using the e-mail option in the last post, e-mails are created in Modest's outbox and can be sent immediately if we're online and that's what's configured, or will be stored in the Outbox until we do get connected. That's one option, if you're happy for the uploads to follow the same defaults as the e-mail client.

If you want to be more sophisticated than that, you'll want to use an incremental backup protocol, such as rsync over SSH, which can synchronise a directory based upon what needs doing at the time. There are plenty of HOWTOs and scripts for the purpose, most of which assume that you'll run the rsync from cron.

You want it only to happen when you're on WiFi; there are a couple of ways that you can achieve that. One is to launch your script from cron but abort silently if we're not on WiFi; an easy way to check that is with iwgetid from the wireless-tools package. You could also use dbus-scripts and react to a connection to a WiFi network, although I haven't found that to be 100% reliable.

magick777, thank you for your wonderful research. I'm curious, maybe it's worth to put incron into Maemo's repos? Installing via wget and dpkg isn't problem, but I think having it in repos (with correct dependency from adduser) would make more people to experiment and create using it, even if they missed our 2 threads.

/Estel

Yes - I think this is useful enough to be available under Maemo by default. Regrettably I don't know how to do that, my experiences with the Maemo development environment aren't worth talking about, but if someone with the skills and the tools wants to package it for Maemo, that would strike me as worthwhile. It would be useful to have the relevant man pages along with it, and probably to undo Debian's "all users disallowed by default" policy, as well.

Then all we'd need is newest curl/libcurl in CSSU and we'd have an easy route to IMAP APPEND...

I would package it for repos - sadly, autobuilder is stuck for a week and a half now, and no one seems to be working on it, so it's quite pointless at the moment.

If and when we do get incron packaged for maemo, that gives rise to a new app idea. At the crudest level, someone could write a GUI for incrontab, which would allow to select directory, monitored events, and command to run.

Better, I see a case for a more generic FileWatcher application that would include some pre-conceived actions to take and the relevant dependencies to make them happen, so we have the functionality of "watch <dir> for newly created files, mask *.jpg, action: e-mail via modest to: <address> Other actions on a per-file level would include FTP upload, WebDAV upload, SSH upload, rsync file, rsync the watched path.

Potentially, this could have a second screen (DirWatcher?) that would offer recursive directory watches using a watcher daemon written in python, such as https://github.com/greggoryhz/Watcher. Gut instinct says that this is less desirable than inotify for mobile applications, but there might be a case for recursively watching a defined "cloud" folder with multiple subdirectories and triggering an rsync on changes to any one of them.

Optionally, it would have a third screen (FSWatcher?) that would watch for mounting and unmounting of filesystems (perhaps by using inotify against /etc/mtab?) and be able to trigger commands upon the connection/disconnection of a filesystem.

I'm not immediately sure exactly how this should be laid out, what it should be called or what functions it should achieve; different people will have different use cases and we might end up with a Photo Sender that's very close to Estel's original notion (quite apart from preserving the images, it could be a safety feature to e-mail them to someone when at a protest) but my thinking is for a lower-level filesystem watcher app, designed to <do whatever we can think of> in response to changes to the filesystem. Maybe it should be possible to "bolt" specific use cases on top of this, so we start with a FileWatcher app (still quite technical in its concept even if we put a GUI on it), then there is a Camera Sender app that leverages the FileWatcher and everything that it depends upon as a backend, but adds the specific features to resize/reformat photo and then do something with it, or to backup&delete all newly-created photos, or whatever. Thoughts?

+1 I think, that Copernicus would be able to patch-up a nice QT GUI for such thing (but, I feel little strange "managing" someone's else time, so take it with a grain of salt - it's based on his being eager for useful programs idea). Well-thought mockups of GUI could be useful, for sure.

But, first, we would need to have it available in repos, which imply having autobuilder repaired *again*...

/Estel