Announcement

Collapse
No announcement yet.

A Network or btrfs "aware" file manager - or a service menu?

Collapse
This topic is closed.
X
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    A Network or btrfs "aware" file manager - or a service menu?

    Background: I have several computers on my home network that I manage remotely, but by far I am most often on my server using ssh. The server is "headless" meaning no GUI so no desktop and no fancy file managers. This server also does content delivery to my devices and transmission - the torrent server. The result is often files obtained using transmission are going to stay on the server for content delivery, but need to be relocated from the download folder to the content folder - music, movies, videos, whatever.

    Note that all these content folders are on the same drive but in different btrfs subvolumes. This is significant because I believe this means to remote tools, they appear to be on separate partitions (sort of) but in reality are not.

    The issue: The media folders are mounted via NFS on my desktop for easy access, but if I move files from one folder (downloads) to another (videos), it takes an incredible amount of time - because the fill has to "travel" from the source folder via the network (kinda guessing here) to my desktop, then back to the server. This delay doesn't happen within a subvolume because Dolphin treats it like a folder as you would expect.

    My current technique is, rather than wait out the lengthy networked file transfer, I log into the server via ssh, navigate to the downloads subvolume and manually "mv" the files to the proper subvolume. This (the file moving part) happens instantaneously because the are actually on the same file system. There may be multiple files and multiple target folders and all the target folders are mounted subvolumes.

    So the dream here is : A file manager that detects the files are actually on the same file system and issues the command to move the files on the remote system rather than the system the file manager is running on.

    I'm curious first of all if such a file manager already exists and I'm just unaware of it. My second idea - since I am not a coder so I'm not making my own file manager - if I can do it locally with a Dolphin Service Menu.

    I'm thinking I can probably do it with Dolphin Service menus since my ssh connection is via secure key so no password required (or even accepted). Even if it had limited functionality - like was only good to move stuff from Downloads to Movies or whatever - I could probably just send an mv command via rsh. Locking down the Service Menu would be of larger concern because I wouldn't want to mis-click and muck something up.

    Just in case someone has a better idea, here's the way it's done now:

    F12 to open Yakuake
    ssh to the server
    cd /mnt/pool/@Downloads/torrentfiles/
    mv <whatever file(s)> ../../@Movies (or one of 5-6 other subvolumes)
    exit ssh

    Not really a lot, but it would be really cool to just do a couple clicks instead. I rarely move the file once they are in place so a one-way Service Menu would probably be fine.

    I tested this rsh command and it works: rsh server mv /mnt/pool/@Downloads/torrentfiles/test /mnt/pool/@Movies/

    so I suppose I just need to write the service menu well enough.

    Please Read Me

    #2
    I wonder if using dolphin's remote mount features will do the job. I don't have a remote to a btrfs to work with as I type to check this out, but maybe if one opened a remote mount in dolphin to the btrfs top level, split the pane so that it's the same mount, navigate in one pane to the source, and the other to the destination, then a quick move might be possible. Dolphin has several remote mount methods, but I usually prefer to use a sshfs mount (with its problems).

    The "mv" command doesn't give control of what it's doing. It first tries the rename, which is link and unlink, and if that won't or doesn't work it tries cp --reflink=auto. In these cases what we want is cp --reflink=always, for it to fail if a full copy is going to happen.
    Regards, John Little

    Comment

    Working...
    X