Leaving files all over home directory

[morenathan]

Seems like every directory or file that I've "boxed up" is in left in my home directory, regardless how I configure it. Here's a simple example:

• name: move ~/.mozilla
  target: ~/.mozilla
  rewrite: ~/config/mozilla
  mode: directory

If I run Firefox, I end up with the directory ~/.mozilla in my home directory. The exception here is that it's empty and everything is in the rewrite location, but the location ~/.mozilla left and a long list (as well as a regular ls in my case) shows it.

Of course there's also files and directories in the location while the application is running too.

Any ideas? I was under the impression there shouldn't be ~/.mozilla if I box it up and have a rule that matches that directory won't exist in ~/ at all. How do I fix this?

[queer]

This is a bug, thank you for reporting!

[queer]

Hi @morenathan, after investigating more, I want to check to be sure: If your ~/.mozilla is just an empty directory, and does exist when boxxy isn't running, does it permanently come back after boxxy ... firefox exits a second time?

[morenathan]

Yes, the directory is empty. What also gives me a chuckle (in a good way) is that files will stick around and they are empty too.

These application directories and files "fill up" while the application is running and then "empty out" when it closes.

Firefox is just an example. Everything in my boxxy.toml file acts this way.

[morenathan]

For reference:

local/boxxy 0.8.5-1
Put bad Linux applications in a box with only their files

From Archlinux "extra" repository.

I could try building boxxy from git. I might do that tonight.

[queer]

I think I know what the bug is here, will try to get to it when I have time. No promises on when that might be unfortunately, health issues are making everything harder right now.

[morenathan]

That I can understand. You have my empathy!

[mesaprotector]

The behavior I've observed with .mozilla is that most often, it'll stick around with only an empty "extensions" directory, but occasionally it'll create the entire firefox profile subfolder which will remain after it's closed (even twice!). Thunderbird does the same with its profile folder. I have noticed that Thunderbird sometimes seems to create .mozilla on its own... which causes problems when writing rules.

Boxxy seems to work fabulously with Discord to get .pki out of $HOME, so at least for me it doesn't happen with every rule.

EDIT: Using nested rules to try to manually capture the subdirectories doesn't work, because though the rules are run in order when the application is launched, the directories are not removed in reverse order when it is closed - instead, it tries removing the parent directory first, which then fails and causes exit with code 1. When called at line 382 of mod.rs, self.created_directories should be in reverse order. self.created_files probably is fine as is. My Rust knowledge is very lacking, sorry.

[ank426]

Any progress?

[queer]

@ank426 There is no update on this, no. As mentioned I do not have a lot of time for working on OSS currently due to ongoing severe health issues, and as such I have little time/energy for things outside of my day job. It is more-likely for this to be closed by someone PRing a fix than for me to be able to get to it right now.

[mesaprotector]

@queer Thank you for all your work, I hope you take time, rest, and recover.

I hope I'm not presuming by trying to help but my impression of how boxxy works is that the unwanted dotfile folders will still show up while the application is running (empty) but should be deleted when it exits. Systemd is fond of SIGKILLing stuff on shutdown, giving boxxy no chance to clean up, so I had to add a bash function (probably better as a systemd service) to take care of that.

With .mozilla (and .thunderbird) specifically it seems you have to change the profile location in the application's own profile manager; I also had to use a nested rule for .mozilla because it kept re-creating /extensions.

@ank426 Could you post a debug log (boxxy -l debug) for an application where this happens?

[queer]

@mesaprotector You’re exactly correct! The temporary files exist at runtime because there needs to be an existing file/directory to bind-mount over. Any aggressive killing of the boxxy process will leave those laying around. CTRL-C is handled but general signal handling isn’t implemented, which may at least help for catching SIGTERM and cleaning up then.

boxxy/src/enclosure/mod.rs

Lines 149 to 156 in fe58be7

	ctrlc::set_handler(move || {
	nix::sys::signal::kill(
	nix::unistd::Pid::from_raw(pid_clone),
	nix::sys::signal::SIGTERM,
	);
	FsDriver::new().cleanup_root(&name_clone);
	exit(1);
	})?;

[ank426]

@queer Thank you for all your work, I hope you take time, rest, and recover.

I hope I'm not presuming by trying to help but my impression of how boxxy works is that the unwanted dotfile folders will still show up while the application is running (empty) but should be deleted when it exits. Systemd is fond of SIGKILLing stuff on shutdown, giving boxxy no chance to clean up, so I had to add a bash function (probably better as a systemd service) to take care of that.

With .mozilla (and .thunderbird) specifically it seems you have to change the profile location in the application's own profile manager; I also had to use a nested rule for .mozilla because it kept re-creating /extensions.

@ank426 Could you post a debug log (boxxy -l debug) for an application where this happens?

Oh. My bad. I mistakenly assumed that the directories wouldn't exist even while the application is running.