[Pkg-wmaker-commits] [wmhdplop] 05/26: wmhdplop: Find disk device after /run transition

[Doug Torrance]

This is an automated email from the git hooks/post-receive script.

dtorrance-guest pushed a commit to branch master
in repository wmhdplop.

commit 60ece7963016e1b7e340c55b0984738e6d866941
Author: Doug Torrance <dtorrance at piedmont.edu>
Date:   Thu Nov 24 10:26:49 2016 -0500

    wmhdplop: Find disk device after /run transition
    
    Patch by Andre Beck <beck at ibh.de> to fix Debian bug #657882.
    
    After the recent /run transition, which also finally turned /etc/mtab into
    a symlink to /proc/mounts, *hdplop (both incarnations) may fail to find a
    single disk device automatically. This is likely due to the root device
    now being exposed as mounted on /dev/disk/by-uuid/$UUID whereas the
    former /etc/mtab as written by mount still contained a device name as
    taken from /etc/fstab, which in my case could be parsed by *hdplop. It's
    unclear if this wouldn't have hit other environments earlier depending
    on their fstab contents, I just assume for now that I'm one of the
    remaining handful of users of this tool ;)
    
    The fundamental issue is of course the rather crude code in devnames.c's
    device_id_from_name() which tries to manually resolve device symlinks,
    but cannot possibly work with any symlink except those located directly
    in /dev - symlinks in subdirectories of /dev will fail.
    
    Impact on wmhdplop: Doesn't start except when called explicitely with
    some "-d /dev/sda" or such option.
    
    Impact on gkrellm-hdplop: Starts but is dazed and confused, leaving a
    black window in gkrellm. Clicking on the black window will then crash
    gkrellm, as it hits an assertion that the device list cannot be empty.
    
    I've prepared a small patch that makes *hdplop work again for me, the
    patch replaces the broken manual symlink resolving by a simple call
    to realpath(3), hopefully not breaking other stuff. I refrained from
    doing any more changes to the code, even though it looks like it needs
    some love. Upstream seems to have lost interest five years ago, though...
    
    So, without much further ado, here's my crude fix:
    
    Don't look too closely, specifically on the strncpy(3) stuff, but I felt
    this is still better than abusing snprintf(3) like the original code does
    some lines above, and as I said, starting to really fix things here looks
    like a bottomless pit...
    
    Thanks,
    Andre.
    
    https://bugs.debian.org/657882
    https://sources.debian.net/src/wmhdplop/0.9.9-5/debian/patches/
      find-disk-device.patch/
---
 devnames.c | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/devnames.c b/devnames.c
index ba7b821..9e93ad2 100644
--- a/devnames.c
+++ b/devnames.c
@@ -186,9 +186,10 @@ int device_id_from_name(const char *devname__, unsigned *pmajor, unsigned *pmino
 
   if (lstat(devname,&stat_buf)) { BLAHBLAH(1,perror(devname)); return -1; }
   if (S_ISLNK(stat_buf.st_mode)) {
-    char lname[512];
-    int n = readlink(devname, lname, 511); lname[n] = 0;
-    snprintf(devname,512,"/dev/%s",stripdev(lname));
+    devname_ = realpath(devname, NULL);
+    if(!devname_) { BLAHBLAH(1,perror(devname)); return -1; }
+    strncpy(devname, devname_, 512); devname[511] = 0;
+    free(devname_);
     if (stat(devname,&stat_buf)) { BLAHBLAH(1,perror(devname)); return -1; }
   }
   if (!S_ISBLK(stat_buf.st_mode)) {

-- 
Alioth's /usr/local/bin/git-commit-notice on /srv/git.debian.org/git/pkg-wmaker/wmhdplop.git