mnttool: notice on failed umount, sync w/ cli umount?

[dentonlt]

This is probably a curaga type question:

Continuing on the mnttool edits ...

Currently there is no warning/notice when mnttool fails to umount. mnttool just continues to display green (mounted). I'd be interested in a brief popup that either says "I can't umount this" or even better "foo and faw have this mount point open." I'm happy to add that code - it should be straightforward to handle the failed system("umount foo") call.

Second, mnttool seems to get out of sync with /mnt/ if the user calls umount or mount via the CLI. Some mount points are displayed green/red when they're not ... or just altogether don't exit. I'm happy to investigate and put in a patch myself.

Main concern is whether the team considers these adding cruft! Else I'll get to it.

[Rich]

Hi dentonlt

Currently there is no warning/notice when mnttool fails to umount. mnttool just continues to display green (mounted).

The fact that it stays green is your warning.

Second, mnttool seems to get out of sync with /mnt/ if the user calls umount or mount via the CLI.

Well sure, you're changing mounted items behind  mnttools  back. Clicking the  Refresh  button should bring it back in sync.

[curaga]

Yeah, changing behind its back is not supposed to work really. A popup for failure would be welcome.

[nitram]

Haven't looked at mnttool and not an experienced coder, just my thoughts. For me popups not appreciated. What about incorporating an idle time out every 10-15 seconds that auto-refreshes mounts when mnttool open. If mismatch between colour indicator and mount results, indicator flashes red/green [edit] or turns yellow [/edit] to notify user of a problem. Cherry on top would be to check if  ntfs-3g  is loaded prior to mounting NTFS partitions, then mount them with  ntfs-3g  command so they are read/write not just read-only. Thanks for your work dentonlt.

[dentonlt]

The fact that it stays green is your warning.

Ha! I'm surprised I hadn't thought of it that way ... You're right, of course.

Yeah, changing behind its back is not supposed to work really.

Maybe that's the main problem I should address. Or at least first.

Cherry on top would be to check if  ntfs-3g  is loaded prior to mounting NTFS partitions, then mount them with  ntfs-3g  command so they are read/write not just read-only.

That's a novel idea. I guess the main question is whether that's suitable to include that sort of code inside of stock/base TC? I don't know if we have other tools/areas that add/extend features dependent upon the presence of optional binaries ... ? At face value, that sounds good to me.

[Misalf]

/usr/sbin/rebuildfstab  already checks for the presence of  ntfs-3g  and creates  /etc/fstab  accordingly. Isn't that used by mnttool?

[nitram]

Just tested in dCore, believe TC6 behaves similarly with NTFS. Added  ntfs-3g  to boot list, rebooted, fstab still read-only for NTFS:
/dev/sda1       /mnt/sda1       ntfs     noauto,users,exec,ro,umask=000 0 0 # Added by TC

Using  mnttool  to mount sda1 results in read-only mount:
touch: cannot touch 'testy': Read-only file system

Umount /dev/sda1 through  mnttool  , manually run  sudo rebuildfstab  still read-only.

Does not appear  rebuildfstab  or  mnttool  recognizes  ntfs-3g  on my system.

@dentonlt: A C++ timeout/reload example from MFMR:

Code: [Select]

#define TIMEOUT_RELOAD 5

/**************************************************************************
*
* Function: idle_function
*
* function to call every TIMEOUT_RELOAD seconds during idle
*  - refresh mount list
*
****************************************************************************/

void idle_function (void *) {

  static time_t time = 0;   
 
  struct stat stat_buffer;

  stat("/etc/mtab", &stat_buffer);
 
  if (time == 0)
 
    time = stat_buffer.st_mtime;
   
  else if (stat_buffer.st_mtime > time) {
   
    ptr_mfmmount->find_mounted();

    time = stat_buffer.st_mtime;
   
  }
 
  Fl::repeat_timeout(TIMEOUT_RELOAD, idle_function);

}


[curaga]

Better hunt that down first. Try adding echoes to rebuildfstab, then run it manually.

[gerald_clark]

nitram, are you sure ntfs-3g actually loaded?

[nitram]

ntfs-3g is loaded at boot in my dCore system:

Code: [Select]

tc@box:/usr/bin$ ls /tmp/tcloop/ | grep ntfs
ntfs-3g/

Thought rebuildfstab was a binary, not.

Think i see the issue, rebuildfstab looks for ntfs-3g in /usr/local/bin:

Code: [Select]

checkntfs() {
  if [ -f /usr/local/bin/ntfs-3g ]; then
      FSTYPE="ntfs-3g"
      OPTIONS="$OPTIONS"
  else
      FSTYPE="ntfs"
      OPTIONS="$OPTIONS,ro,umask=000"
  fi
}

In dCore-jessie it's here:

Code: [Select]

tc@box:/usr/bin$ which ntfs-3g
/bin/ntfs-3g

Modifying rebuildfstab:

Code: [Select]

checkntfs() {
  if [ -f /usr/local/bin/ntfs-3g ] || [ -f /bin/ntfs-3g ]; then
      FSTYPE="ntfs-3g"
      OPTIONS="$OPTIONS"
  else
      FSTYPE="ntfs"
      OPTIONS="$OPTIONS,ro,umask=000"
  fi
}

...gets proper fstab:

Code: [Select]

/dev/sda1       /mnt/sda1       ntfs-3g  noauto,users,exec    0 0 # Added by TC

...and mnttool mounts the NTFS partition read/write as expected.

[nitram]

Couple other observations, the  [ -f /bin/ntfs-3g ] addition for Ubuntu-based dCores would be welcome too:
http://packages.ubuntu.com/wily/i386/ntfs-3g/filelist

My bad regarding TC6, NTFS does mount read/write with mnttool when ntfs-3g loaded. It does not, however, umount with mnttool until i close both the terminal and MFMR, even though the NTFS partition was no longer the working directory. Maybe a terminal or file manager issue, unsure. In this situation a yellow flashing button or simillar may be useful when umount attempt fails, so at least the user knows it's not a mouse clicker issue and they can investigate further.

[Rich]

Hi nitram

It does not, however, umount with mnttool until i close both the terminal and MFMR, even though the NTFS partition was no longer the working directory.

If you back out of the mounted directory prior to closing MFMR does umount succeed then? If MFMR actually changes the
current working directory and then exits to a terminal the directory might still be in use.

In this situation a yellow flashing button or simillar may be useful when umount attempt fails, so at least the user knows it's not a mouse clicker issue and they can investigate further.

Two colors seems pretty clear to me. Green means it's mounted, red means it's not. If it stays red, mount failed. If it stays
green, umount failed. As far as the "mouse clicker" is concerned, the mount button gives visual feedback. Place the mouse
pointer over a mount button and press the mouse button. The mount button will change from colored to gray. Release the
mouse button and the mount button changes from gray to colored.

[curaga]

That's a dCore-specific path, so that change is better applied just to dCore scripts then.

[jls]

why use the full path?

[nitram]

Thanks, never noticed the change to grey when click-happy, good enough.
This would be robust for any future path changes, TC and dCore, even piCore:

Code: [Select]

if [ `which ntfs-3g`=="TRUE" ]; then