WelcomeWelcome | FAQFAQ | DownloadsDownloads | WikiWiki

Author Topic: mnttool: notice on failed umount, sync w/ cli umount?  (Read 5523 times)

Offline dentonlt

  • Sr. Member
  • ****
  • Posts: 318
    • the trombone analog
mnttool: notice on failed umount, sync w/ cli umount?
« on: July 23, 2016, 07:03:05 PM »
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.

Offline Rich

  • Administrator
  • Hero Member
  • *****
  • Posts: 11178
Re: mnttool: notice on failed umount, sync w/ cli umount?
« Reply #1 on: July 23, 2016, 08:01:49 PM »
Hi dentonlt
Quote
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.
Quote
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.

Offline curaga

  • Administrator
  • Hero Member
  • *****
  • Posts: 10957
Re: mnttool: notice on failed umount, sync w/ cli umount?
« Reply #2 on: July 24, 2016, 01:21:14 AM »
Yeah, changing behind its back is not supposed to work really. A popup for failure would be welcome.
The only barriers that can stop you are the ones you create yourself.

Offline nitram

  • Hero Member
  • *****
  • Posts: 1054
Re: mnttool: notice on failed umount, sync w/ cli umount?
« Reply #3 on: July 24, 2016, 09:12:53 AM »
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.
« Last Edit: July 24, 2016, 09:17:38 AM by nitram »

Offline dentonlt

  • Sr. Member
  • ****
  • Posts: 318
    • the trombone analog
Re: mnttool: notice on failed umount, sync w/ cli umount?
« Reply #4 on: July 25, 2016, 04:13:03 AM »
Quote
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.

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

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

Quote
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.



Offline Misalf

  • Hero Member
  • *****
  • Posts: 1702
Re: mnttool: notice on failed umount, sync w/ cli umount?
« Reply #5 on: July 25, 2016, 04:31:16 AM »
/usr/sbin/rebuildfstab  already checks for the presence of  ntfs-3g  and creates  /etc/fstab  accordingly. Isn't that used by mnttool?
Download a copy and keep it handy: Core book ;)

Offline nitram

  • Hero Member
  • *****
  • Posts: 1054
Re: mnttool: notice on failed umount, sync w/ cli umount?
« Reply #6 on: July 25, 2016, 05:28:37 AM »
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);

}

Offline curaga

  • Administrator
  • Hero Member
  • *****
  • Posts: 10957
Re: mnttool: notice on failed umount, sync w/ cli umount?
« Reply #7 on: July 25, 2016, 10:30:45 AM »
Better hunt that down first. Try adding echoes to rebuildfstab, then run it manually.
The only barriers that can stop you are the ones you create yourself.

Offline gerald_clark

  • TinyCore Moderator
  • Hero Member
  • *****
  • Posts: 4254
Re: mnttool: notice on failed umount, sync w/ cli umount?
« Reply #8 on: July 25, 2016, 12:18:53 PM »
nitram, are you sure ntfs-3g actually loaded?

Offline nitram

  • Hero Member
  • *****
  • Posts: 1054
Re: mnttool: notice on failed umount, sync w/ cli umount?
« Reply #9 on: July 25, 2016, 01:12:00 PM »
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.

Offline nitram

  • Hero Member
  • *****
  • Posts: 1054
Re: mnttool: notice on failed umount, sync w/ cli umount?
« Reply #10 on: July 25, 2016, 06:33:08 PM »
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.

Offline Rich

  • Administrator
  • Hero Member
  • *****
  • Posts: 11178
Re: mnttool: notice on failed umount, sync w/ cli umount?
« Reply #11 on: July 25, 2016, 10:16:22 PM »
Hi nitram
Quote
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.

Quote
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.

Offline curaga

  • Administrator
  • Hero Member
  • *****
  • Posts: 10957
Re: mnttool: notice on failed umount, sync w/ cli umount?
« Reply #12 on: July 26, 2016, 01:06:38 AM »
That's a dCore-specific path, so that change is better applied just to dCore scripts then.
The only barriers that can stop you are the ones you create yourself.

Offline jls

  • Hero Member
  • *****
  • Posts: 2135
Re: mnttool: notice on failed umount, sync w/ cli umount?
« Reply #13 on: July 26, 2016, 03:56:56 AM »
why use the full path?
dCore user

Offline nitram

  • Hero Member
  • *****
  • Posts: 1054
Re: mnttool: notice on failed umount, sync w/ cli umount?
« Reply #14 on: July 26, 2016, 08:41:31 AM »
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