Automatically delete empty QubesIncoming subdirectories

Yes, that manpage is wrong (in a characteristically GNU way)


find "${path}" -depth -type d -empty -delete

Super elegant! :+1:

I picked your command line for the first post because it’s just better in all ways :slight_smile:

1 Like

You need to keep -mindepth 1 to not remove /home/user/QubesIncoming and you either need to specify $path variable or specify path to directory:

test ! -d /home/user/QubesIncoming || find /home/user/QubesIncoming -mindepth 1 -type d -empty -delete


qubes_incoming_path='/home/user/QubesIncoming' && test ! -d "$qubes_incoming_path" || find "$qubes_incoming_path" -mindepth 1 -type d -empty -delete

The command above does not delete QubesIncoming even if it’s empty

It does for me:

user@testqube:~$ mkdir /home/user/QubesIncoming
user@testqube:~$ find /home/user/QubesIncoming -depth -type d -empty -delete
user@testqube:~$ ls -la /home/user/QubesIncoming
ls: cannot access '/home/user/QubesIncoming': No such file or directory

What’s the need to keep ~/QubesIncoming? (As far as I can tell, it gets created if needed whenever you copy files to a qube.)


my bad, I have an hidden file to prevent this directory to be backuped! This prevented deletion.

I have this directory in Nautilus as a bookmark, Nautilus isn’t happy when the directory disappear

1 Like

In those few cases where this is an issue (most of my VMs are disposables), I just go into QubesIncoming and issue rmdir *, ignoring the “not empty” error messages. I could certainly automate this in .bashrc.

If I wanted to delete QubesIncoming itself (provided it’s empty) of course I could add a line to do that as well.

Solene of course could skip that last step.

For DRY, re-use the last argument to the previous command.
For not removing the folder itself, it seems that subfolders can be used as targets for find .

test ! -d /home/user/QubesIncoming ||
    find "${_}/"* -depth -type d -empty -delete

Of course, many options.

I don’t know why, but i typed this now, from my mobile :crazy_face: … so untested (and perhaps mistyping), should be compatible with quite a few shells that have: test, printf, find, read.

#!/usr/bin/env sh

    usage() {
        >&2 printf 'usage:\npath=~/QubesIncoming/ %s' "$0"

# ask input if unset & stdin (0) is connected to a terminal
    test -t 0 &&
            >&2 printf 'What path? '
            read p
            printf '%s' "$p"

# exit script if $path is unset,
# unless there is a $default_path to set it to
    : path="${path:-${default_path?-no $path and no $default_path to set $path to}}"

    test -d "${path?}" &&
            findArgs='-type d -empty'
            test ! -t 0 ||
# stdin tty-connected, ask confirmation
                    >&2 {
                         printf 'To be deleted:\n'
                         printf '%s' $(
                             find "${path?}/"* $findArgs -depth -print
                         printf 'Delete paths? [y/N] '
                    read confirmed
                    test -z "${confirmed%y}" -o -z "${confirmed%Y}"
# $? is 0 when stdin is not a tty
# or, when $confirmed is y or Y
        test $? -eq 0 &&
            find "${path?}/"* $findArgs -delete
$ test ! -d /home/user/QubesIncoming ||
    find "${_}/*" -type d -empty -delete
find: ‘/home/user/QubesIncoming/*’: No such file or directory

You can also remove -depth option sine according to the man it’s automatically turns on by -delete option:

The use of the -delete action on the command line automatically turns on the -depth option.

ah, yes, that’s right.

the asterisk needs to move outside.

Also, assuming there are no spaces in ~ , the quotes can be removed.

To delete the existing QubesIncoming as well:

test ! -e ~/QubesIncoming ||
    find $_ -type d -empty -delete

To keep/guarantee QubesIncoming is there, without empty subdirectories:

mkdir -p ~/QubesIncoming &&
    find ${_}/* -type d -empty -delete
1 Like

I use a simpler approach.
My ~/QubesIncoming is on a RAM drive. In /rw/config/rc.local I have:

mount -o remount,size=2G /tmp
mkdir -p /tmp/download -m 700
chown -R user:user /tmp/download
ln -sfT /tmp/download /home/user/QubesIncoming

So, everything deletes itself automatically on qube shutdown + I also have a convenient directory for storing other volatile stuff.

1 Like

Mounting “something else” to ~/QubesIncoming can help out with other situations too.

If I want to move a big file to my NAS (mounted on nas-qube) from some other-qube that cannot access the NAS, normally one would do a qvm-copy to nas-qube, and then copy from nas-qube:~/QubesIncoming/other-qube onto the NAS.

That involves writing redundantly to the SSD that Qubes is installed on; if you’re worried about wearing out your SSD, this could be a consideration.

However if you mount the NAS storage to QubesIncoming, then the copy goes directly to the NAS. (I was originally going to mount a ramdisk as you did, but then realized for what I was trying to do, this is simpler. Besides there might not be enough RAM for it to work for large files.)

This, by the way also applies to other kinds of storage (CD/DVD/Bluray burner, a thumb drive) if you want to have a qube dedicated to mounting that storage.

That involves writing redundantly to the SSD that Qubes is installed on; if you’re worried about wearing out your SSD, this could be a consideration.

This is a real concern. Unfortunately, due to the way Qubes OS works, moving a file from qube-A to qube-B (with persistence) also means copying, then deleting of the original (which is not true deletion on SSD technology). On a local file system, that would not result in SSD wear but cross-qube… I wonder if there is a solution to this technical inefficiency as it results in actual hardware amortization (+ overhead, as IIUC, qube-A and qube-B use separate encryption keys). Do you know anything about it? Any existing issues/discussions?

As far as I know mounting something else (ramdisk, like you mentioned in connection with deleting the directories, or some other storage) to QubesIncoming (or QubesIncoming/source-qube-name solves the problem…the copy then is directly TO that device rather than to storage in the destination qube which is really on the host SSD.

Returning to the topic of deleting empty QubesIncoming/* directories, one option is to use disposables (either named ones, which most of mine are, or disp1234); of course the directories go away when the qube shuts down. Most of my qubes are disposables, though QubesIncoming/* directories do accumulate on the rest.