New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Error when using a non-start disk for location of personal files. #1389

Open
ghost opened this Issue Nov 10, 2017 · 19 comments

Comments

4 participants
@ghost
Copy link

ghost commented Nov 10, 2017

I have two disks in my laptop, a small SSD for the operating system and programs and a large HDD for my files. Both have been added to /etc/fstab to show up on boot. When I tried to add my actual pictures, documents... folders from my HDD, I got an error. I don't know why, maybe it has to do with the names of these folders? I use spaces, numbers and non-ASCII characters in the folder names. Could that be the source of the problem?

Just to make it clear: From the picture, it looks like I am using folders in my /home/einar/ folder, but I am not. The names of the folders changed back to the defaults as the error came up. The folders I tried to set was on another disk mounted at boot to /run/media/einar/Magnus_Super/ and they open up fine in PCManFM. I am not using the HDD for my ~, but I am using folders on it to store my files.

error when using a non-startdisk for locations for personal files

Expected Behavior

I should be able to set these folders to any folder mounted on my system.

Current Behavior

I get the error only when trying to set folders on my HDD as the personal files folder.

Possible Solution
Steps to Reproduce (for bugs)

Open LXQt session settings, change folders to folders on another disk.

Context
System Information
  • Distribution & Version: Arch Linux
  • Kernel:
  • Qt Version:
  • liblxqt Version: 0.12.0-1
  • Package version: 0.12.0-1

@agaida agaida added this to Needs triage in Issues Jul 14, 2018

@agaida agaida moved this from Needs triage to High priority in Issues Jul 15, 2018

@agaida

This comment has been minimized.

Copy link
Member

agaida commented Jul 15, 2018

there is a similar bug in Launchpad

@tsimonq2

This comment has been minimized.

Copy link
Member

tsimonq2 commented Jul 15, 2018

For the record, this is the LP bug report @agaida is referencing.

@agaida agaida moved this from High priority to Low priority in Issues Aug 24, 2018

@agaida agaida moved this from Low priority to High priority (release-blockers) in Issues Oct 2, 2018

@scott092707

This comment has been minimized.

Copy link

scott092707 commented Nov 2, 2018

The bug report referenced by tsimonq2 is mine, and the bug still exists post-release of Lubuntu 18.10.

I also attempted to change my user directories with the session-settings->user directories app, and
had the same error message upon "Close" that is shown in the above picture.

[Since this did not work, I went back to my usual manual change of user-dirs.dirs, followed by log out/in.
I note that the change in user-dirs.dirs did NOT alter what was shown in session-settings->user directories. It still showed "/home/scott/..." ]

I also note that each time the browse icon is clicked for a directory, it forces one to start at /home/ .
Since probably all user directories are in the same containing directory, if the user navigates to a different containing directory, the next time he clicks on "browse", it might for the user's convenience, default to the same containing directory the user browsed to before.
Since there are eight user directories to change, this means for me, that I need to click:
up / up / up to get to "/", then double click on /data, and then double click on /data/scott,
and finally double click on the relevant user directory (or select the directory and click on "Choose")
eight different times to change all the user directories.
Alternatively, you could have a radio button that if clicked, would change all containing directories to the same one. (If subsequently un-checked, one could change one or two oddball directories that didn't fit the pattern of all user directories being in the same containing directory.)
Or something like that...

@agaida

This comment has been minimized.

Copy link
Member

agaida commented Nov 2, 2018

Ok, we should close this now - @tsujan, do you agree? - Maybe there should be a follow up bug to make the messages more verbose.

IMHO Folders outside the $HOME should not be considered as valid settings for xdg user dirs. - Maybe i'm wrong, one should check the spec about.

@agaida agaida moved this from High priority (release-blockers) to Needs triage in Issues Nov 2, 2018

@tsujan

This comment has been minimized.

Copy link
Member

tsujan commented Nov 2, 2018

We require that dirs should be inside home: https://github.com/lxqt/libqtxdg/blob/7d7e6e7a898529feb1293ceb9c4a3c6be083fac4/src/qtxdg/xdgdirs.cpp#L182 . So, the error message is expected. Whether this condition can be loosened is another question but one can guess that it may not be safe.

@agaida

This comment has been minimized.

Copy link
Member

agaida commented Nov 2, 2018

We should improve the message that way that directories outside home are not allowed. things like symbolic links or (better) bind mounts wasn't invented yesterday.

@tsujan

This comment has been minimized.

Copy link
Member

tsujan commented Nov 2, 2018

We should improve the message

Yes, "An error occurred..." is too general when we know what has happened in the code.

BTW, I'm not so brave to loosen that condition.

@tsujan

This comment has been minimized.

Copy link
Member

tsujan commented Nov 2, 2018

Oh, my bad: we don't know what has happened because there are 3 cases of return false;.

Of course, the code can be changed so that messages are more specific but I'm not sure it's worth the effort for such rare cases.

NOTE: GitHub got confused AGAIN! This is alarming.

@tsimonq2

This comment has been minimized.

Copy link
Member

tsimonq2 commented Nov 4, 2018

We require that dirs should be inside home: https://github.com/lxqt/libqtxdg/blob/7d7e6e7a898529feb1293ceb9c4a3c6be083fac4/src/qtxdg/xdgdirs.cpp#L182 . So, the error message is expected. Whether this condition can be loosened is another question but one can guess that it may not be safe.

But why? I can't think of a good reason why this is the way it is.

@tsujan

This comment has been minimized.

Copy link
Member

tsujan commented Nov 4, 2018

I can't think of a good reason

Because you're very brave.

@agaida

This comment has been minimized.

Copy link
Member

agaida commented Nov 4, 2018

very brave != dont care

there are a bunch of "solutions" in the wild - linking the needed directories into users home (fugly) - bind mount it into users home (better) - using user mounts (far better) and so on

@tsujan

This comment has been minimized.

Copy link
Member

tsujan commented Nov 4, 2018

very brave != dont care

Right.

I'm not sure about Qt's reaction. It should be thoroughly tested by someone (not me; I can't).

@tsujan

This comment has been minimized.

Copy link
Member

tsujan commented Nov 4, 2018

Qt aside (it shouldn't complain, I think), older codes may suppose that those folders are inside $HOME. I'm not even sure that we don't have such codes.

@agaida

This comment has been minimized.

Copy link
Member

agaida commented Nov 4, 2018

@tsimonq2 made yesterday a noteworthy comment about upgrading from LXDE to LXQt - "We don't support it." - So i would like to make the same comment here and now: We just don't support that, there are alternatives. Educate the users about and be done with.

@tsimonq2

This comment has been minimized.

Copy link
Member

tsimonq2 commented Nov 4, 2018

@tsimonq2 made yesterday a noteworthy comment about upgrading from LXDE to LXQt - "We don't support it."

If you're going to quote me, quote me correctly. 😛

I said that installing LXQt on an 18.04 system and LXDE on 18.10 isn't supported; I said nothing about 18.04 -> 18.10 upgrades, that's what our documentation is for.

I'll do some testing in Lubuntu with removing that conditional. If it breaks nothing (which it won't 😛) I'll report back.

@tsujan

This comment has been minimized.

Copy link
Member

tsujan commented Nov 4, 2018

If it breaks nothing...

So, you know that you need to test it on your system and with those folders outside your home and with as many apps as you could install for at least a month.

@tsujan

This comment has been minimized.

Copy link
Member

tsujan commented Nov 4, 2018

We just don't support that, there are alternatives.

I agree. @tsimonq2 thinks just "doing some tests" is enough.

@scott092707

This comment has been minimized.

Copy link

scott092707 commented Nov 4, 2018

I guess people weren't understanding the rationale of what I was doing...

When I set up my computer (lo, those many years ago...), I read something about how to set up my partitioning.
I have 5 different partitions in which I can install OSes (originally, to try different distros, but long since merely for subsequent versions of the same distro - Lubuntu).
If an install goes kerflewy, I can just boot into the previous one and try and find out what is wrong and try and fix it. Also, I can just re-purpose an earlier distro's partition to test an OS's development version,
and still use my usual OS partition for day-to-day work.

What I read was, that even if I keep my personal data in a separate partition, it is still a good idea to have $HOME in the OS's install partition, because any installed app will put its config folders in $HOME, and from one distro version to the next, the config data may change. If $HOME resides with my personal data in a separate partition, then each install will wipe out and replace the app config data, so that if I try to go back and use a previous distro version, the apps may not work correctly, as they are now trying to run with later config data. (And unless I rename all my personal folders to something other than the standard names, I suppose they would get erased, too...)

So, saying that my personal data MUST be in $HOME does not make logical sense (to me, at least...):
that would mean that either I make my install partition the whole drive (so there's room for all my personal data), and therefore have no way to boot multiple OS's, or $HOME is in my data partition, and the app config files get munged every time I test a new distro (or fail to install a new version, and try to go back to a previous one).
Neither way is very appetizing...

@agaida

This comment has been minimized.

Copy link
Member

agaida commented Nov 4, 2018

@scott092707 - you might be surprised, i understand the rationale very well, i use this setup with minor variations since eight years and wrote endless rants about. To make it short: It seems to me that you missed some points about *nix filesystems and the used tree structure. Nothing important, but worth to think about it. Otherwise: Congratulations for a fine setup, right now my laptop and my workstation with some installations are built that way (approx 12 different installations, arch, debian, siduction, lubuntu, freebsd included)

Right now i have a small 500G SSD called datagrave in the workstation among other drives:

mount /dev/sd?1 /mnt/datagrave
----
mount --bind /mnt/datagrave/agaida/work /home/agaida/work
mount --bind/mnt/datagrave/agaida/Documents /home/agaida/Documnets
# and so on

Voila, my files are in my $HOME, done - as i wrote above, linking would work too.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment