0

Problem: I have some bookmarks in Nautilus (v3.8.2) that point to folders that are part of a Truecrypt volume that I mount after logging into the system. The problem is that as this happens after logging in, Nautilus during the session start cannot find them and thus ignores them so they don't appear in the left panel.

Workaround #1: I can open the Nautilus' bookmarks editor, rearrange the bookmarks back and forth and Nautilus reloads their list in the left panel. However, it's annoying to do it manually all the time.

Workaround #2: I can kill Nautilus as suggested in another question and when I start it again, it shows all the bookmarks. Unfortunately this requires opening Nautilus because after killing it, all the desktop icons disappear.

QUESTION: Is there some other way I can force this reload? Something I could incorporate into a bash script and make it happen automatically few minutes after the session start.

Note: Please, don't suggest use of another file manager. I know that for example Nemo doesn't have this problem but this question is about finding solution for Nautilus.

tmt
  • 1,029
  • How about a startup script that watches the mount point of the encrypted volume and restarts Nautilus? – muru Jul 17 '14 at 11:01
  • Yes, that would be good. It seems you added your comment at the same time as I edited my question adding workaround #2. It's the "restart Nautilus" that doesn't seem to be easy. – tmt Jul 17 '14 at 12:01
  • xrefresh works great on 22.04. Thanks! – Kevin Berry May 21 '22 at 18:41

1 Answers1

1

Restarting nautilus is fairly easy:

nautilus -q
nautilus -n &
disown

Unfortunately sometimes this sequence of commands doesn't work, probably due to some race condition. And so we might have to do a pkill or killall.

To watch the mount point directory of the encrypted volume, you can poll a file within it:

FILE=/path/to/some/file/in/encrypted/volume
while sleep 10s; do
    if [[ -f $FILE ]]; then
        pkill nautilus # or nautilus -q
        nautilus -n &
        disown
        exit
    fi
done

I mistakenly assumed that inotify could be used, but it can't since mounting is involved.

muru
  • 197,895
  • 55
  • 485
  • 740
  • Killing Nautilus works fine. :-) It's the starting again that doesn't seem to work. It hangs with the message "Could not register the application: GDBus.Error:org.freedesktop.DBus.Error.NoReply: Message did not receive a reply (timeout by message bus)" – tmt Jul 17 '14 at 12:40
  • Wait a second... I have now been playing with it and it actually sometimes works and sometimes doesn't. It always produces some warning/error messages and it never exits for some reason but it does start nautilus half of the time. – tmt Jul 17 '14 at 12:48
  • @cascaval Ah. In the system in which I tested, it always gave an error message similar to that. Does forcing a sequence between the kill and start change things? nautilus -q && nautilus -n? – muru Jul 17 '14 at 13:13
  • No, that doesn't change anything. Sometimes it fails with the error message I already mentioned, sometimes it works while producing other messages. – tmt Jul 17 '14 at 13:25
  • OK, this doesn't work for me but the approach seems to be good so maybe it's still going to be useful for someone else. +1 – tmt Jul 18 '14 at 07:22
  • @cascaval I played around with it a bit. While nautilus -q; nautilus -n & disown gave me errors on occasion, pkill nautilus; nautilus -n & disown hasn't given errors yet. Can you try that? – muru Jul 18 '14 at 07:44
  • It still gives errors that I posted yesterday but now it consistently works. 2 things: 1) When Nautilus is started and the errors are displayed, it doesn't exit. It just "hangs" after the errors. (I hope you understand what I mean.) 2) Would the loop in your script ever stop? (I've read what disown does and don't really understand it.) – tmt Jul 18 '14 at 08:21
  • @cascaval Oh damn! This is what happens when you take a break when writing an answer. There was to be an exit after the disown (edited to fix it). disown essentially separates the first job from the shell, so that closing the terminal won't kill it. See http://unix.stackexchange.com/a/3887/70524 It is to handle the "hanging" that I decided to send it to the background and disown it (nohup would have worked fine too). Also, as long as the GDBus error doesn't happen, I think nautilus starts fine. The other errors are of the sort I often see when running GUI programs from the terminal. – muru Jul 18 '14 at 08:27
  • Cool. Thank you very much for the time you've spent on your answer! – tmt Jul 18 '14 at 08:40
  • One more thing: Shouldn't the condition be -d $FILE if I'm checking for a directory? – tmt Jul 18 '14 at 08:56
  • @cascaval Yes. You can look up the list of tests using help test. – muru Jul 18 '14 at 08:59
  • Can you please alter your answer so that somebody else doesn't get stuck on it? After all it says "To watch the encrypted directory". – tmt Jul 18 '14 at 09:02
  • @cascaval I edited it. I hope it's clearer. – muru Jul 18 '14 at 09:07
  • Good improvement but no change of that -f $FILE? :-) – tmt Jul 18 '14 at 09:14
  • @cascaval No, you see, I am checking for the appearance of a file in in the encrypted directory. The directory will remain a directory before and after you have mounted the volume, so that check will always return true. But if you check for a file that only exists in the encrypted volume, when it appears, you'll know that the mount has occurred. The negated test can be used for a file that only exists in the directory before you mount anything on it – muru Jul 18 '14 at 09:22
  • 1
    Oh, alright, that's good then. In my case I'm checking for a bookmarked directory inside the mounted volume, so the check would return true only if the volume is mounted. Anyway, let's leave this finally. Thanks again for your support! – tmt Jul 18 '14 at 09:48