kup reports "Broken filename passed to function" when trying to start a new backup

When started the backup, I am able to see the backup plan asks if I want to save a first backup. However, when I click Yes, nothing happens. I killed kup-daemon process and started manually, and I am seeing the errors:

kf.notifications: Failed to notify "Created too many similar notifications in quick succession"
Broken filename passed to function
Broken filename passed to function
Broken filename passed to function

I downloaded source code from Kup repository and searched for “Broken filename passed to function”, but not able to have any findings. I would like to know what I can do next to fix this issue.

hi, welcome.

tell us about your system by providing the output of kinfo

and share the 4 tabs of details about the backup plan that is failing.

what is the output of bup version

Hello,

kinfo output:

Operating System: Debian GNU/Linux 13
KDE Plasma Version: 6.5.2
KDE Frameworks Version: 6.20.0
Qt Version: 6.9.2
Kernel Version: 6.17.13+deb14-amd64 (64-bit)
Graphics Platform: Wayland
Processors: 20 × 13th Gen Intel® Core™ i7-13700H
Memory: 16 GiB of RAM (15.2 GiB usable)
Graphics Processor: Intel® Iris® Xe Graphics

bup version output:

bup version
0.33.7

Tabs:

(Sorry I can only paste one screenshot per post due to forum restriction)

that all looks normal

when you plug in the external storage do you find an archive there or no?

do you have anything in ~/.bup?

you may need to bup init the repository to be on the storage device instead of your home dir.

or you can add the path with including

export BUP_DIR=

to your ~/.profile

No, I have no /home/**/.bup directory at all.

On the other hand, do you mean that I have to manually run something for kup?

Your logs will be sort of hidden, as they are in ~/.cache/kup
These might be useful, especially if the error is in bup itself. If the error message is actually accurate, it should shopw if an y files have odd filenames, or something saimilar.

You won’t have a ~/.bup dir unless Debian does something different from other distros. You don’t need one, for use with Kup.

A long shot, but it might be worth trying the initial backup without verification or creating recovery data, or a separate plan for testing, storing a small number of files to a different location.

Actually:

(My brane just clicked on) How is the destination drive formatted? I will bet it does need to be a Linux filesystem (ext4, btrfs). I have been using Kup for quite a few years, but I can’t recall any issues, but I have been using either ext4, btrfs, or remote NFS shares, so file names, formatting, and unix style permissions are not an issue.

you do not need a ~/.bup but if you had one it would indicate that you are not pointed at the storage location you thought you were pointed at.

you didn’t say if there is any archive on the external storage, did you create a partition there for the backups?

I just reformatted the disk using btrfs, Still seeing the same error.

Yes, just reformatted the disk and created an empty btrfs partition, which is the only partition in that drive. Still seeing the same issue

Continue debugging the issue.

Installed the debug symbol for kup-backup:

sudo dpkg -i kup-backup-dbgsym_0.10.0-1+b1_amd64.deb

Run kup-daemon using gdb

gdb kup-daemon

and put breakpoints when printing out to stdout/stderr

(gdb) b write if 1==$rdi
(gdb) b write if 2==$rdi

After start a new backup:

(gdb) bt
#0  __GI___libc_write (fd=2, buf=0x7fffffffca40, nbytes=35) at ../sysdeps/unix/sysv/linux/write.c:26
#1  0x00007ffff5a955f5 in _IO_new_file_write (f=0x7ffff5bf24e0 <_IO_2_1_stderr_>, data=0x7fffffffca40, n=35) at ./libio/fileops.c:1182
#2  0x00007ffff5a938d2 in new_do_write (fp=fp@entry=0x7ffff5bf24e0 <_IO_2_1_stderr_>, data=data@entry=0x7fffffffca40 "Broken filename passed to function\n", to_do=to_do@entry=35) at ./libio/libioP.h:1041
#3  0x00007ffff5a957f9 in _IO_new_file_xsputn (f=0x7ffff5bf24e0 <_IO_2_1_stderr_>, data=<optimized out>, n=35) at ./libio/fileops.c:1256
#4  _IO_new_file_xsputn (f=0x7ffff5bf24e0 <_IO_2_1_stderr_>, data=<optimized out>, n=35) at ./libio/fileops.c:1198
#5  0x00007ffff5a641d2 in __printf_buffer_flush_to_file (buf=buf@entry=0x7fffffffca10) at ../libio/libioP.h:1041
#6  0x00007ffff5a64290 in __printf_buffer_to_file_done (buf=buf@entry=0x7fffffffca10) at ./stdio-common/printf_buffer_to_file.c:120
#7  0x00007ffff5a6ee0d in __vfprintf_internal (s=0x7ffff5bf24e0 <_IO_2_1_stderr_>, format=0x7ffff6448c99 "%s\n", ap=ap@entry=0x7fffffffcb10, mode_flags=2) at ./stdio-common/vfprintf-internal.c:1560
#8  0x00007ffff5b25a3f in ___fprintf_chk (fp=<optimized out>, flag=<optimized out>, format=<optimized out>) at ./debug/fprintf_chk.c:33
#9  0x00007ffff6137065 in ?? () from /lib/x86_64-linux-gnu/libQt6Core.so.6
#10 0x00007ffff613df21 in ?? () from /lib/x86_64-linux-gnu/libQt6Core.so.6
#11 0x00007ffff613717b in ?? () from /lib/x86_64-linux-gnu/libQt6Core.so.6
#12 0x00007ffff612e781 in ?? () from /lib/x86_64-linux-gnu/libQt6Core.so.6
#13 0x00007ffff60dc8c9 in QMessageLogger::warning(char const*, ...) const () from /lib/x86_64-linux-gnu/libQt6Core.so.6
#14 0x00007ffff6102bcf in ?? () from /lib/x86_64-linux-gnu/libQt6Core.so.6
#15 0x00007ffff614a203 in ?? () from /lib/x86_64-linux-gnu/libQt6Core.so.6
#16 0x000055555556c1e1 in EDExecutor::ensureAccessible (this=this@entry=0x5555558558c0, pReturnLater=@0x555555855970: false) at ./daemon/edexecutor.cpp:122
#17 0x000055555556c294 in EDExecutor::startBackup (this=0x5555558558c0) at ./daemon/edexecutor.cpp:87
#18 0x00007ffff61ff521 in ?? () from /lib/x86_64-linux-gnu/libQt6Core.so.6
#19 0x00007ffff7eec24c in ?? () from /lib/x86_64-linux-gnu/libKF6Notifications.so.6
#20 0x00007ffff61ff521 in ?? () from /lib/x86_64-linux-gnu/libQt6Core.so.6
#21 0x00007ffff7ef8cef in ?? () from /lib/x86_64-linux-gnu/libKF6Notifications.so.6
#22 0x00007ffff61ff521 in ?? () from /lib/x86_64-linux-gnu/libQt6Core.so.6
#23 0x00007ffff7f07694 in ?? () from /lib/x86_64-linux-gnu/libKF6Notifications.so.6
#24 0x00007ffff7f0814f in ?? () from /lib/x86_64-linux-gnu/libKF6Notifications.so.6
#25 0x00007ffff6f04437 in ?? () from /lib/x86_64-linux-gnu/libQt6DBus.so.6
#26 0x00007ffff61f0c94 in QObject::event(QEvent*) () from /lib/x86_64-linux-gnu/libQt6Core.so.6
#27 0x00007ffff71b9c48 in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /lib/x86_64-linux-gnu/libQt6Widgets.so.6
#28 0x00007ffff61a6928 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from /lib/x86_64-linux-gnu/libQt6Core.so.6
#29 0x00007ffff61a6b97 in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () from /lib/x86_64-linux-gnu/libQt6Core.so.6
#30 0x00007ffff6407e37 in ?? () from /lib/x86_64-linux-gnu/libQt6Core.so.6
#31 0x00007ffff51f2385 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#32 0x00007ffff51f45b7 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#33 0x00007ffff51f4d20 in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#34 0x00007ffff6404dc8 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /lib/x86_64-linux-gnu/libQt6Core.so.6
#35 0x00007ffff61afe53 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /lib/x86_64-linux-gnu/libQt6Core.so.6
#36 0x00007ffff61a9701 in QCoreApplication::exec() () from /lib/x86_64-linux-gnu/libQt6Core.so.6
#37 0x0000555555561b17 in main (argc=<optimized out>, argv=<optimized out>) at ./daemon/main.cpp:60

so EDExecutor::ensureAccessible triggered that message. Function body:

bool EDExecutor::ensureAccessible(bool &pReturnLater)
{
    pReturnLater = false; // reset in case we are here for the second time
    if (!mStorageAccess) {
        return false;
    }
    if (mStorageAccess->isAccessible()) {
        if (!mStorageAccess->filePath().isEmpty()) {
            mDestinationPath = mStorageAccess->filePath();
            mDestinationPath += QStringLiteral("/");
            mDestinationPath += mPlan->mExternalDestinationPath;
            QDir lDir(mDestinationPath);
            if (!lDir.exists()) {
                lDir.mkpath(mDestinationPath);
            }
            QFileInfo lDestinationInfo(mDestinationPath);
            if (lDestinationInfo.exists() && lDestinationInfo.isDir()) {
                return true;
            }
        }
        return false;
    }
    connect(mStorageAccess, &Solid::StorageAccess::accessibilityChanged, this, &EDExecutor::updateAccessibility);
    mStorageAccess->setup(); // try to mount it, fail silently for now.
    pReturnLater = true;
    return false;
}

and the line triggered the issue is if (!lDir.exists()).

Printing out lDir

(gdb) p lDir
$3 = {d_ptr = {d = 0x5555555dfdf0}}
(gdb) p lDir.path()
$4 = {d = {d = 0x5555557bdd10, ptr = 0x5555557bdd20 u"/media/CENSORED/Backup", size = 28}}

Checking out the path:

/bin/ls Backup/ -ald
drwxrwxrwx 1 root root 0 Jan  7 22:53 Backup/

seems have permissions to all. Able to create directory in the Backup disk. Tried to debug furthermore but I cannot find debug symbols for Qt in Debian stable. Any suggestions?

Other than suggesting to submit a bug report, I can’t add much.

Actually, just for testing, can you create a different plan to a different device, drive, or directory?

Are there any contents in the log files at all, if any are created?

maybe try a plain ext4 for fat32 and see if you get different results and generate a new partition table before you do it.

I have just tried to backup /home/xxx/Document to /home/xxx/.bup and it dramatically worked.

So something about the external drive may be the cause. Permissions/ownerships, I will guess.

You can chown the mount point (likely in /media/<username> or set things up when creating the partition.

Nah, I tried to format the partition using either btrfs or ext4, none worked.

Actually… I have fixed the issue by not specifying the backup destination as an External Drive, but used “local” filesystem at /media/xxx/Backup. It seems I lose the advantage of starting backup when the device plugs in, but at least it works.