Version 7.x uses /dev/loop0 (at least on my n900) instead of /dev/mapper/truecrypt1...problem is, loop0 exists whether or not a decrypted TC volume is present, so can't use it's existence to trigger the script change.

As for regular partitions dedicated as truecrypt devices, they're mounter as /dev/mapper/truecrypt1, truecrypt2 and so goes on... While testing your code, I was using one of such partitions, yet, it failed for me

nmap and others, could You test approach with

Now, I wonder why "regular" mass-storage of MyDocs require umounting it from device... I've just tested this approach with my /dev/mmcblk1p1 (first partition of microSD card, vfat), and it also works - it's accessible through both N900 and desktop.

Works for me with /dev/loop0

BTW You can see where the decrypted volume block file is with "truecrypt -l"

It probably doesn't require it per se, but developers probably thought it a bad idea to have a volume mounted in two places at once. In general I think I agree.

You can use N900's encrypted partitions via mass-storage mode, *without* need for TrueCrypt installed on desktop (all decrypted in N900, transparently for desktop). This way, You can use content of Your encrypted volumes in desktops, without actually using them to input passwords/keyfiles = no risk, that software or hardware keyloggers attached to said desktops, will catch your password. Just remember, that it *doesn't* protect Your encrypted volume from getting unwanted files written by malware, or even being deleted/overwritten, if connected in read&write mode.

It's very simple to achieve - just execute in terminal (as root):
...replacing [your-encrypted-device] with path to Your encrypted device (*not* partition containing it). Examples:
It's very easy, to determine, where Your encrypted device is located - just execute:
in terminal. First column is partition/container location, 2nd one is Your encrypted device location, and 3th is mountpoint for actual file access. You use 2nd one, as argument for mass-storage'ing.

Side note:
If, for any reasons, You want simple code to grep your encrypted device location, by providing it's actual location (partition or encrypted file container), you can use this (courtesy of NIN101):
...where [path to volume] should be replaced with path to partition or file container (for example, /dev/mmcblk1p2, or /home/user/MyDocs/my-encrypted-file-container).

It doesn't have any benefit over writing argument directly, but may be useful, if You're planning to write simple GUI for that, or to include support for it in your program.

Known flaws:
Mass-storage'd volumes doesn't respect special filesystem options passed to Maemo by trueCrypt, during mounting (they're still valid for Maemo, but not for desktop). So, if You mount Your volume with read-only flag, and latter mass-storage it, desktop will be able to write to it anyway. Of course, Maemo still respects read and write flags. If You want to export volume for desktop via mass-storage in read-only state, you must create Your copy of [b]osso-usb-mass-storage-enable.sh (remember to chmod +x it afterwards), edit it to use read-only, and use it instead of vanilla osso-usb-mass-storage-enable.sh, everytime You want to export volume as read-only.

Known "special" benefits:
As for volumes with ''Hidden volume protection'', mass storage respect it and provide some kind of extended plausible deniability. Such volume, when exported to desktop via mass-storage, still protect blocks of hidden volume, yet *doesn't* throw any warnings on desktop side. Furthermore, "blocked" file appear to be written successfully from desktop side. For example, if You copy music file, that gets write blocked, it's fully usable from desktop, as long as You don't disconnect mass-storage and connect it again.

That is, You can have, lets say, 20MB outer volume, with 15MB hidden volume inside, then copy 17MB music file to outer volume (obviously, with "hidden Volume Protection", it will get blocked as soon as it reach any hidden volume block), and then, perfectly play it from desktop - from start to the end. Also, using "safe device removal" will not pop-up any errors.

in reality, such file will be copied only in part that was written to outer volume, with rest just plain cut-off (in my tests, I was able to play such music file furthermore, but instead 3 minutes, it played only for 29 seconds).

Of course, I've tested it with another music file occupying 98% of hidden volume, and despite "writing" repeatedly many different files to outer volume (from desktop, via mass-storage mode), file on hidden volume was kept intact.

Only one moment, when You'll get notification "warning, TrueCrypt protected hidden volume from damage (...)", is when You unmount TrueCrypt containers (if you've followed my advice and disabled "background task").

(technical explanation of this phenomena)
When volumes are mounted successfully with hidden volume protection, they're mounted as encrypted loop devices (for example, /dev/loop0). Unlike filesystem options (like read and write flags), which are set at later part - while mounting encrypted device as actual access point for filesystem (i.e. /media/truecrypt1), thus ignored by mass-storage target desktop - "hidden volume protection" is set as special option of such loop device. As we export loop device as mass-storage, protecting bits are respected, yet desktop OS doesn't have a clue about them, and isn't informed. Common sense would tell, that during "Safe Device Removal", desktop's Os should be informed about "delayed write fail", yet, it seems that it's not informed about any failures, and consider operation finished OK.

Normally, this would be bug, but in our case, it's a feature providing additional benefit

It's *heavily* recommended, to turn TrueCrypt background task off - in our case, it doesn't provide any true benefit, yet consumes ~17MB of memory and CPU cycles. To do it, from TrueCrypt GUI enter "Settings -> Preferrences -> Background Task (Tab)" and untick "Enabled".

Rationale? If it's just aesthetic, I'm going to fix it for my device ASAP, as:

works flawlessly, and I can access volume from *both* N900 and desktop simultaneously! So, in my case, part of instructions from NIM101, telling that you need to mount without filesystem, isn't true.

Mass-storage'd volumes doesn't respect special filesystem options passed to Maemo by trueCrypt, during mounting (they're still valid for Maemo, but not for desktop). So, if You mount Your volume with read-only flag, and latter mass-storage it, desktop will be able to write to it anyway.

that instead of writing quite sophisticated '/usr/sbin/osso-usb-mass-storage-enable.sh `truecrypt -t -l | grep [path to volume] | cut -f3 -d" "`'...

@nman
Thanks for checking with root. As for not choosing "mass storage mode" you're of course right - yet, even if one choose to, it *still* works after executing
MyDocs get just "replaced" on desktop by encrypted volume.

By the way, do you have any idea, how to properly modify osso-usb-mass-storage-enable.sh, to mount lun0 as read-only?

@NIN101
Unless good enough reason (with technical rationale) is provided, I'm not going to re-use Nokia way "because they know better". Anyway, on my device, vanilla osso-usb-mass-storage-enable.sh already set MMC for simultaneous access (that is, don't unmount it), I'm using it like that from the very beginning, and haven't run into *any* single issue.