mount .iso plugin

Should be fairly easy to add this command yourself to the right-click menu
for .iso-files, shouldn't it?

Post by Liviu Andronic
Dear Tom,
Would you consider adding a 'Mount ISO image' plugin? It is very easy
mkdir /mnt/test
mount -o loop -t iso9660 file.iso /mnt/test
But having a plugin doing this would so much more elegant. The mount
point could actually be in /tmp. Perhaps this would fit the
file.unpack? What do you think?
Regards,
Liviu
--
Do you know how to read?
http://www.alienetworks.com/srtest.cfm
http://goodies.xfce.org/projects/applications/xfce4-dict#speed-reader
Do you know how to write?
http://garbl.home.comcast.net/~garbl/stylemanual/e.htm#e-mail
--
Users can unsubscribe from the list by sending email to
by logging into the web interface.

Serge

2013-12-26 14:03:11 UTC

Yeah, i think mount iso plugin is unneeded thing.
I am using fuseiso for example, very useful.
"fuseiso -n -p %f %f.mount" - mount iso in current directory.
"fusermount -u %f" - unmount it.

On Wed, 25 Dec 2013 19:48:30 +0100

--
Claws Mail version 3.8.1
Linux debian 3.2.0-4-rt-amd64 #1 SMP PREEMPT RT Debian 3.2.53-2 x86_64
GNU/Linux

t***@onepost.net

2013-12-27 01:24:55 UTC

On Wed, 25 Dec 2013 19:48:30 +0100

Post by Liviu Andronic
Would you consider adding a 'Mount ISO image' plugin? It is very easy
mkdir /mnt/test
mount -o loop -t iso9660 file.iso /mnt/test
But having a plugin doing this would so much more elegant. The mount
point could actually be in /tmp. Perhaps this would fit the
file.unpack? What do you think?

Liviu, a plugin for that seems like overkill to me.

I'd suggest the following:

Create aliases for your specific mount and unmount commands
perhaps including variable(s) for mountpoints e.g. ISOMOUNT=someplace

Add the aliases to a custom menu (for any toolbar), and/or to filelist context-menu user-commands, and/or to key-bindings.

Regards
Tom

Liviu Andronic

2013-12-27 15:13:42 UTC

Post by Serge
On Wed, 25 Dec 2013 19:48:30 +0100

Liviu, a plugin for that seems like overkill to me.

Well, in my view even unpacking a .tar.gz or .zip or .7z archive can
be considered overkill, if you think hard about it. But we do have a
plugin for that, and it is useful. Although I admit that handling .iso
images is perhaps more esoteric than it could be, it would still be a
useful addition to the default actions shipped with emelFM2,
especially for the casual emelFM2 user.

More to the point, even if a stretch, .iso files can be considered as
archives. And file.unpack and file.pack could be set to handle these
files, too: unpack (mount) to some temporary location, delete
(unmount) or repack if the user so wishes. It seems to me (although I
may be mistaken) that most of the infrastructure is already there, and
not much is needed to make it happen.

Regards,
Liviu

Post by Serge
Create aliases for your specific mount and unmount commands
perhaps including variable(s) for mountpoints e.g. ISOMOUNT=someplace
Add the aliases to a custom menu (for any toolbar), and/or to filelist context-menu user-commands, and/or to key-bindings.
Regards
Tom
--

Liviu Andronic

2014-01-19 10:30:16 UTC

Dear Tom,
I see that you implemented support for .iso files in file.unpack in
r2868. Thanks!

A couple of queries:
- Would it make sense to now support by default the 'iso' filetype
and bind it to file.unpack (and, perhaps,
http://www.littlesvr.ca/isomaster/ )?

- If I file.unpack an .iso and then hit 'back' and answer 'delete',

mount -o loop "/home/liv/Downloads/iso/gparted-live-0.17.0-4-i486.iso" . (11053)
mount -o loop ... nloads/iso/gparted-live-0.17.0-4-i486.iso" . (11053) returned '0'

Cannot delete /tmp/0-emelfm2-svn-unpack.tmp~2 - Resource temporarily unavailable

Moreover, the temporary mount point doesn't get unmounted:
***@malou-laptop:~$ cat /etc/mtab | grep -i emel
/dev/loop0 /tmp/0-emelfm2-svn-unpack.tmp~2 udf rw 0 0

- Although the mounted fs is 'rw':
***@malou-laptop:~$ cat /etc/mtab | grep -i emel
/dev/loop0 /tmp/0-emelfm2-svn-unpack.tmp~3 udf rw 0 0

The actual mount point doesn't seem to have 'w' permissions:
***@malou-laptop:~$ ls -l /tmp | grep -i 0-emelfm2-svn-unpack.tmp~3
dr-xr-xr-x 8 root root 416 Dec 29 07:13 0-emelfm2-svn-unpack.tmp~3

Is this intended?

Regards ,
Liviu

On Wed, 25 Dec 2013 19:48:30 +0100

Liviu, a plugin for that seems like overkill to me.
Create aliases for your specific mount and unmount commands
perhaps including variable(s) for mountpoints e.g. ISOMOUNT=someplace
Add the aliases to a custom menu (for any toolbar), and/or to filelist context-menu user-commands, and/or to key-bindings.
Regards
Tom
--

t***@onepost.net

2014-01-21 23:02:51 UTC

On Sun, 19 Jan 2014 11:30:16 +0100

Post by Liviu Andronic
Dear Tom,
I see that you implemented support for .iso files in file.unpack in
r2868. Thanks!
- Would it make sense to now support by default the 'iso' filetype
and bind it to file.unpack

Reluctant to do this, for now at least. I'm not convinced it will ever work satisfactorily.

The included command 'mount -o ....", and hence unpacking iso files, only works for superuser.

Even as superuser, I get this message:
mount: /dev/loop0 is write-protected, mounting read-only

(and, perhaps,

Post by Liviu Andronic
http://www.littlesvr.ca/isomaster/ )?

IMHO, things like this utility are a good reason not to bother with iso's in e2.

Post by Liviu Andronic
- If I file.unpack an .iso and then hit 'back' and answer 'delete',

mount -o loop "/home/liv/Downloads/iso/gparted-live-0.17.0-4-i486.iso" . (11053)
mount -o loop ... nloads/iso/gparted-live-0.17.0-4-i486.iso" . (11053) returned '0'

Cannot delete /tmp/0-emelfm2-svn-unpack.tmp~2 - Resource temporarily unavailable
/dev/loop0 /tmp/0-emelfm2-svn-unpack.tmp~2 udf rw 0 0

The plugin now includes an unmount command for iso's during cleanup.

Post by Liviu Andronic
/dev/loop0 /tmp/0-emelfm2-svn-unpack.tmp~3 udf rw 0 0
dr-xr-xr-x 8 root root 416 Dec 29 07:13 0-emelfm2-svn-unpack.tmp~3
Is this intended?

No, but see comment above about write-protection.

Regards
Tom

Liviu Andronic

2014-01-25 18:53:28 UTC

Post by t***@onepost.net
On Sun, 19 Jan 2014 11:30:16 +0100

Post by Liviu Andronic
- Would it make sense to now support by default the 'iso' filetype
and bind it to file.unpack

Reluctant to do this, for now at least. I'm not convinced it will ever work satisfactorily.
The included command 'mount -o ....", and hence unpacking iso files, only works for superuser.

Agreed, this could cause user confusion if not used as root. Wouldn't
there be a different approach, say using fuse (but I'm shooting in the
dark here), which wouldn't require root?

Post by Liviu Andronic
http://www.littlesvr.ca/isomaster/ )?

IMHO, things like this utility are a good reason not to bother with iso's in e2.

There are few such utilities (I only know one), and they're not always
as useful as a plain mounted .iso that you can browse in your
favourite FM. This said, would you consider adding filetype .iso bound
by default to this 'isomaster'? (Actually I now discovered a second
such utility, furiusisomount: https://launchpad.net/furiusisomount .)

Post by t***@onepost.net
The plugin now includes an unmount command for iso's during cleanup.
mount -o loop "/home/liv/Downloads/iso/gparted-live-0.17.0-4-i486.iso" . (18324)
mount -o loop ... nloads/iso/gparted-live-0.17.0-4-i486.iso" . (18324) returned '0'
umount /tmp/0-emelfm2-svn-unpack.tmp~6 (18343)
umount /tmp/0-emelfm2-svn-unpack.tmp~6 (18343) returned '0'

Cannot delete /tmp/0-emelfm2-svn-unpack.tmp~6 - No such file or directory

However /tmp/0-emelfm2-svn-unpack.tmp~6 is actually still present on the FS.

Post by Liviu Andronic
/dev/loop0 /tmp/0-emelfm2-svn-unpack.tmp~3 udf rw 0 0
dr-xr-xr-x 8 root root 416 Dec 29 07:13 0-emelfm2-svn-unpack.tmp~3
Is this intended?

No, but see comment above about write-protection.

Then I suspect that 'repack' is not on the cards here (I actually get
a crash when I opt for 'repack'). Can this item be disabled in the
dialogue?

Regards,
Liviu

Post by t***@onepost.net
Regards
Tom
--

t***@onepost.net

2014-02-03 06:05:06 UTC

On Sat, 25 Jan 2014 19:53:28 +0100

Post by t***@onepost.net
On Sun, 19 Jan 2014 11:30:16 +0100

Post by Liviu Andronic
- Would it make sense to now support by default the 'iso' filetype
and bind it to file.unpack

Reluctant to do this, for now at least. I'm not convinced it will ever work satisfactorily.
The included command 'mount -o ....", and hence unpacking iso files, only works for superuser.

Agreed, this could cause user confusion if not used as root. Wouldn't
there be a different approach, say using fuse (but I'm shooting in the
dark here), which wouldn't require root?

IMHO that would be moving into the area of 'uncommon' installed applications, which are best not hard-coded into the plugin.

Back to users setting up their own, via filetypes, aliases etc.

Post by Liviu Andronic
http://www.littlesvr.ca/isomaster/ )?

IMHO, things like this utility are a good reason not to bother with iso's in e2.

Again, how likely are isomaster etc to be installed ?

Cannot delete /tmp/0-emelfm2-svn-unpack.tmp~6 - No such file or directory
However /tmp/0-emelfm2-svn-unpack.tmp~6 is actually still present on the FS.

Post by Liviu Andronic
/dev/loop0 /tmp/0-emelfm2-svn-unpack.tmp~3 udf rw 0 0
dr-xr-xr-x 8 root root 416 Dec 29 07:13 0-emelfm2-svn-unpack.tmp~3
Is this intended?

No, but see comment above about write-protection.

Then I suspect that 'repack' is not on the cards here (I actually get
a crash when I opt for 'repack'). Can this item be disabled in the
dialogue?

Re-packing seems to work now, though I've not verified the integrity of the newly-replaced .iso file

Something for Liviu to play with ....

Regards
Tom

Liviu Andronic

2014-02-07 21:27:08 UTC

Post by t***@onepost.net
Again, how likely are isomaster etc to be installed ?

Well, to me this is another example of the limits of emel's flexible,
but static file type scheme.

For example, is it sane to assume by default that people have
installed OpenOffice (but not LibreOffice)? Or Mozilla (but not
Chromium)? Muine or XMMS (but not Clemantine, gnumiscbrowser, etc.)?
The strangest default binding is 'gview'; here by default it simply
loads gVim instead of some image viewer. And what about 'geeqie' or
'viewnior' (but not Mirage or Ristretto)? And Totem (but not VLC or
Gnome-MPlayer)? And not considering that emel comes with a filetype
for 'lzma', but not for 'iso'. (For example, I have none of the above
defaults installed, but I do work on word-like documents, open .html
files, listen to music and display images.)

What I mean is that as much as emel's flexible filetype scheme is
useful (it really is!), it becomes a drawback on new installations or
for the casual user. The static filetype scheme is unable to pick up
any application changes on the user's system (unlike Thunar, for
example), and needs extensive effort to customize. Of course you can
just copy the config file from a machine to the other, but that's not
always available and it's unnecessary overhead when you can't keep
track of the systems you're using: adjust the scheme in one place,
then copy to the other systems, etc.

In this sense the recent file.<handlers> addition is useful, but
incomplete. For one it's slow (at least in my experience). It is also
limited, handling only the default action known to the system (for a
given filetype). Perhaps a Thunar-style "Open With > [..]" would help,
but I'm not sure what the best solution here would be.

In any case best would be to somehow combine the best of both worlds
(in a way similar to what we already have). Having only the static
filetype is insufficient, even if helpful in other cases. If better
integration with system filetype scheme can be achieved, then emel
wouldn't even need to bind 'Mozilla' or Opera by default in its own
scheme; it would only need to include internal solutions (file.unpack,
file.view, etc.). Then the user could add others if so necessary, but
this arrangement would be so much neater.

Post by Liviu Andronic
Then I suspect that 'repack' is not on the cards here (I actually get
a crash when I opt for 'repack'). Can this item be disabled in the
dialogue?

Re-packing seems to work now, though I've not verified the integrity of the newly-replaced .iso file

As far as I can see, mounting an .iso is only allowed read-only (see
http://unix.stackexchange.com/questions/26237/iso-file-readonly ). So
re-packing would likely not work with this approach, as no
modifications are possible.

Regards,
Liviu

t***@onepost.net

2014-02-07 23:59:59 UTC

On Fri, 7 Feb 2014 22:27:08 +0100

Post by t***@onepost.net
Again, how likely are isomaster etc to be installed ?

Establish relevant filetypes information once, use the configuration plugin to export, and later import filetypes for whoever/wherever you want.

We could support a variant of the -c commandline option, which specifies a (presumably shared) place for config data but only for reading at session start.

or

Post by Liviu Andronic
for the casual user.

This case may indeed be a problem.

The static filetype scheme is unable to pick up

Post by Liviu Andronic
any application changes on the user's system (unlike Thunar, for
example), and needs extensive effort to customize. Of course you can
just copy the config file from a machine to the other, but that's not
always available and it's unnecessary overhead when you can't keep
track of the systems you're using: adjust the scheme in one place,
then copy to the other systems, etc.
In this sense the recent file.<handlers> addition is useful, but
incomplete. For one it's slow (at least in my experience). It is also
limited, handling only the default action known to the system (for a
given filetype). Perhaps a Thunar-style "Open With > [..]" would help,
but I'm not sure what the best solution here would be.

In general, it doesn't make sense to ask the user what to use to 'open' an item when such choice is supposed to be reflected in the filetypes data, except perhaps as a fallback after the 'normal' command fails. The latter process is achievable via a context menu, because "Open with" and desktop-environment-known applications are presented there. I suppose such a fallback mechanism could be automated, though the practical advantage (one less right-click) would be minimal.

Post by Liviu Andronic
In any case best would be to somehow combine the best of both worlds
(in a way similar to what we already have). Having only the static
filetype is insufficient, even if helpful in other cases. If better
integration with system filetype scheme can be achieved,

Filetypes config data could support a token for "system-defined default application", e.g. <system application> %p.

If so, should it be translated, as are other tokens like <submenu> ?

then emel

Post by Liviu Andronic
wouldn't even need to bind 'Mozilla' or Opera by default in its own
scheme; it would only need to include internal solutions (file.unpack,
file.view, etc.). Then the user could add others if so necessary, but
this arrangement would be so much neater.