Optimizer breaks shared HFS+ partitions

[SrGMC]

I'm running elementary OS on a MacBook alongside with macOS. I also have a partition with my home folder (shared between both OSs, let's call it Data). This partition is formatted as HFS+ and it's mounted it in elementary OS with hfsplus.

When I run Optimizer, in cleaner mode, with all the options selected, pressing the "Clean Up" button does nothing. No prompts, no loading bars, nothing. But when I press the button again, it completely freezes elementary OS. You can't do anything besides moving the cursor. The only way to shutdown the computer is closing the lid, waiting a few minutes, login in with another account with admin permissions, then opening the terminal and typing sudo shutdown now. It then takes forever to shutdown (spent almost one hour trying to shutdown, before forcefully shutting down the computer).

After that, if you try to boot up elementary OS, the system completely refuses to load and takes me back to the login screen. Otherwise, if you try to boot macOS, it throws an error, similar to this (partition names are different):

Meaning that the partition is corrupted and can only be backed up and reformatted.

Here's basic system information:

• eOS and macOS are installed by following this guide.
• MacBook Air 2015.
• macOS Mojave 10.14.3 (APFS 32GB partition).
• elementary OS 5.0 Juno built on Ubuntu 18.04.2 LTS with Linux 4.15.0-47-generic (ext4 32GB partition).
• 64GB HFS+ Data partition.
• Optimizer 1.1.0.

[hannesschulze]

I am so sorry that this has happened to you and I'll do my best to resolve this issue.

However, looking at the code, I don't really know why this has happened - and I don't think that the HFS+ partition is really important in this case.

At first, Optimizer creates a list of folders that you have selected (code) If this list isn't empty, it will create a Granite.MessageDialog (code) and right after that it creates a little Toast that should show up, saying Calculating file size... (code) - I don't know what could go wrong until this point, so it should have displayed this message at least. Calculating the size might take about a minute, depending on the number and size of the files.

After that, things get a little bit more complicated, because Optimizer creates another thread, so that the UI doesn't freeze when it's calculating the size. In this thread, Optimizer goes through each directory that you have selected and each subdirectory and file inside of them and so on (code). It then calculates a total size for each directory and a creates list for every file inside of it (code). But this should be only read access, and it shouldn't access any mounted partitions.

After this is done, it should show a MessageDialog listing all of the files and their size (code), but this didn't happen in your case.

How long did you wait until you clicked the button again? And how long did you use this setup? - The only reason I can currently see is that there are problems when accessing the filesystem using Gio in multiple threads at the same time - however, as I said, Optimizer should at least show the Calculating file size... Toast for 2 seconds I think. And even if there are problems, there should have been only read access to the disk and that shouldn't break the filesystem.

If that is the case, I think I have to disable the button when it's still calculating the file size or something like that

Again, I'm really sorry that this has happened to you.

[SrGMC]

Don't worry. No files were lost and it was a simple fix.

How long did you wait until you clicked the button again?

I think it was between 30 seconds and 1 minute.

And how long did you use this setup?

For almost a year now. This problem has only ocurred 2 times.

The only reason I can currently see is that there are problems when accessing the filesystem using Gio [...]

This is the first thing that came to my mind. The HFS+ partition is mounted on boot with fstab. Correct me if I'm wrong, but probably, since the HFS+ partition is mounted in / and the "Monitored filsystem" is set by default to /, switching between drivers of different filesystems might be modifying what it shouldn't and causing this failure.

I should comment that the implementation of HFS+ in Linux is sometimes a bit unstable.

A possible solution that occurs to me (which I don't know if it's possible) would be not to access directories that are on a partition with a different filesystem than the system (e.g. HFS+ vs ext4), or not accessing and ignoring HFS+ partitions. In my case .cache and .local (both directories checked by Optimizer) are on this shared partition.

Regarding to other filesystems other than those of the system, I will try to check, mainly out of curiosity, whether the same problem, with same setup, happens with NTFS or FAT partitions.

[hannesschulze]

Don't worry. No files were lost and it was a simple fix.

Ok, that was my biggest fear :p

I think it was between 30 seconds and 1 minute.

For such an "old" setup, there might be pretty many files to check in the directories, so this time is pretty normal (it took about 3 minutes on a system that was used regularly for 2 years) - so I will go ahead and make the button inactive while it's calculating, so that nobody clicks it while it is still in progress.

A possible solution that occurs to me (which I don't know if it's possible) would be not to access directories that are on a partition with a different filesystem than the system (e.g. HFS+ vs ext4), or not accessing and ignoring HFS+ partitions

Unfortunately, I don't know if that is really possible since Optimizer uses libgtop to check the available disk space, but I'm not sure if it's got something to do with the monitoring tbh.

I will also check if I can reproduce this issue myself in a VM

[SrGMC]

I've tried reproducing the bug in a VM with no success. elementary OS on an ext4 partition and /home/user on a JFS partition worked, although the first time I ran Optimizer, it only displayed an error banner. Restarting the app worked though.

Edit: My bad :/ . I didn't set the permissions right and I've noticed now that none of the apps were working as expected.

elementary OS on an ext4 partition and /home/user on a HFS+ partition (with hfsprogs) worked without any problems at all.

This is the toast I was not getting

It seems that the problem is with the instability of the hfsplus package, as hfsprogs works without any problems, so it seems the problem is not on your side.

Anyways, making the Clean Up button insensitive is still a good feature because I've seen myself, while testing:

• Clicking this button two times as if Optimizer was unresponsive (caused by the VM to be a bit slow) and opening two file list popups.
• Clicking this button two times by accident (again, caused by the VM) opening another two file list popups.

This will also assure to the user that the program is doing things and prevent misclicks.

[hannesschulze]

I also wasn't able to reproduce this issue, but I also think that making the button insensitive might solve some of the reasons it happened to you.

Do you think we can close this issue now, or do you have any other ideas?

[SrGMC]

Yes, we can close this now

Thank you for your responses!