On 2021-03-10 at 21:22, Cmdte Alpha Tigre Z wrote: >> I don't see why that would come up in this case. >> >> In the model I described, the original paths which you found >> confusing are all still there, and anything which wants to find >> things under them can continue to use them. >> >> All this model does is give those paths an additional name each, >> and maybe go out of its way to hide the original names from you. >> Just because there are new names, and you can't see the old ones >> when you use one specific way of looking, doesn't mean that they >> aren't there or that other things can't see them. > > Oh, now I understand what you mean, instead of doing it like the > merge of /usr, you would make the new paths and not the old ones to > be symbolic links. Yes, it should not break anything. Thanks. > > I have one question, does it work without breaking anything if I mark > the old directories with a hidden atribute instead of some file > manager specific configuration? If that type of mark is possible in your environment, then no, this shouldn't break anything. However, as far as I'm aware, there is no non-file-manager-specific "hidden" attribute for an *nix filesystem. The traditional way to make most *nix programs treat a file as hidden is to rename the file so that it starts with a '.' character - and renaming any of these directories would, of course, bring back in the "existing programs can't find what they expect" problem. The need to introduce, or take advantage of, a file-manager-specific "hidden" attribute is exactly the reason why I think a specialized file manager for the purpose would probably be needed. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw
Attachment:
signature.asc
Description: OpenPGP digital signature