https://bugs.kde.org/show_bug.cgi?id=436439

--- Comment #5 from Duncan <1i5t5.dun...@cox.net> ---
(In reply to hchain from comment #3)
> What's more, the migration does attempt to avoid running more than once, by
> either deleting the autostart-scripts directory if it is empty after the
> migration, or renaming it to old-autostart-scripts if there are still files
> inside.
> 
> Could the renaming have failed on your machine ? perhaps due to a permission
> issue ?

So I've been looking at the code and trying to figure out what happened, not
exactly easy for someone far more comfortable in bash than C++, tho I can sort
of read it and even occasionally patch it successfully if I stare at it for
long enough...

What do I do to turn on the qCInfo/qCDebug output?  Because I have a theory or
two I'd like to test, and a backup copy of my old autostart and
autostart-scripts dirs I can copy back in place to test with.

The best theory is a followup on that permissions issue remark.  My GUI-user
owned both dirs, which had 0750 permissions while the config parent had 0o0700
perms.  All files in the autostart-scripts dir were symlinks and the target was
obviously readable (perms 0o0740 FWIW) or they'd have not been executing
previously.

But the symlinks were all root owned.[1]  Of course that shouldn't matter
unless the dirs are set sticky (they weren't, 0o0750 perms not 0o1750).  But if
something aborted on root ownership even if it shouldn't matter for symlinks...

So I'd like to do a trial run using the files and perms from my backups, with
that qCInfo/qCDebug stuff turned on, maybe even adding a couple more debug
lines, and see what comes out.  But to do that I need to know how to turn it on
and where to look for the output...

---
[1] I could have sworn that back in the day, kernel 2.4/2.6 kde2/3 era, all my
symlinks were root owned.  Maybe reiserfs handled them that way or 2.4 in
general did??  But I can't seem to find anything to back that up and I've
looked, so maybe it was just my being new to *ix back then.  In any case
current btrfs lets non-root own symlinks.  But I remember stopping short when I
first noticed them and wondering what had changed.

-- 
You are receiving this mail because:
You are watching all bug changes.

Reply via email to