Saving failes when relative pathnames used on command line
Starting MuseScore like 'musescore path/to/file.mscx' makes it fail to save; an strace shows it tries to access 'path/to/path/to/file.mscx' intermittently. Starting it with the full path ('musescore /home/foo/path/to/file') succeeds.
lasconic suggested in IRC to resolve pathnames from the command line to their absolute paths early. (Just take care to not break symlinks.)
Comments
I can't reproduce on Mac OS with 2.0.3 or with a nightly. Are you really using MuseScore 2.0.3? If yes, it could be limited to linux.
I can't reproduce the bug on Linux with 2.0.3.
This still happens with 2.1 on GNU (Debian GNU/Linux sid/x32):
tglase@tglase:~ $ strace -e file -o foo musescore mbsd/mirsol/music/free/Abendlied.mscx
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-tglase'
Qt: XKEYBOARD extension not present on the X server.
^C
130|tglase@tglase:~ $ fgrep Abendlied foo
execve("/usr/bin/musescore", ["musescore", "mbsd/mirsol/music/free/Abendlied"...], [/* 45 vars */]) = 0
stat("/home/tglase/mbsd/mirsol/music/free/Abendlied.mscx", {st_mode=S_IFREG|0644, st_size=223839, ...}) = 0
open("mbsd/mirsol/music/free/Abendlied.mscx", O_RDONLY|O_CLOEXEC) = 19
stat("mbsd/mirsol/music/free/Abendlied.mscx", {st_mode=S_IFREG|0644, st_size=223839, ...}) = 0
access("mbsd/mirsol/music/free/Abendlied.mscx", W_OK) = 0
open("mbsd/mirsol/music/free/Abendlied.mscx.temp", O_WRONLY|O_CREAT|O_TRUNC|O_CLOEXEC, 0666) = 19
stat("mbsd/mirsol/music/free/.Abendlied.mscx,", 0xffd4f3f0) = -1 ENOENT (No such file or directory)
stat("mbsd/mirsol/music/free/mbsd/mirsol/music/free/Abendlied.mscx", 0xffd4f3f0) = -1 ENOENT (No such file or directory)
lstat("mbsd/mirsol/music/free/Abendlied.mscx.temp", {st_mode=S_IFREG|0644, st_size=223839, ...}) = 0
stat("mbsd/mirsol/music/free/Abendlied.mscx", {st_mode=S_IFREG|0644, st_size=223839, ...}) = 0
See the path doubling in the stat call. Screenshot also attached, of the situation where I pressed ^C.
Could be this in libmscore/scorefile.cpp:
“name” is the complete relative path, and if the renaming is attempted relative to “dir”, which could be inside the directory, it would match the strace output. Unfortunately, strace in Debian is not compiled with libunwind, and gdb is not very helpful either:
My C++-fu is not strong enough for this.
This indeed looks like the smoking gun, although I don't quite understand why then an absolute filename (one starting with /) works?
I would guess that {targetdirectory}.rename({absolutepath}, {basename}) works because it’s an absolute path in the first argument, which doesn’t get the path of targetdirectory prepended, while a relative one does.
cf. https://github.com/musescore/MuseScore/pull/3310
Fixed in branch 2.2, commit 5d01db16a2
fix #150956: saving scores opened by relative pathname from cmdline
Fixed in branch master, commit 28a54f3963
fix #150956: saving scores opened by relative pathname from cmdline
Automatically closed -- issue fixed for 2 weeks with no activity.