So, like I mentioned in the 53029 booting problem topic, Haiku doesn’t just fail to copy the files in the writable folders inside /home/config, it fails silently with no mention whatsoever of this failure to the user.
This is a very serious mishandling of a users files, and is completely unacceptable!
UPDATE: Not only does Haiku do the above bad things, it also Kernel Panics when you manually copy the sub-folders of /home/config and then try to delete them from the copy destination!
I guess you have to be more specific. I have several Haiku installations on different partitions. I can mount such a partition and copy e.g. the files in ~/config/non-packaged/bin/ to the ~/config/non-packaged/bin/ of that other partition. Or replace the whole non-packaged folder.
May you suffer some filesystem corruption? Have you tried “checkfs”?
Has anyone claimed something different (if it is reproducible by others)? Why this pre-emptive aggression?
The backup destination is a USB thumb drive, formatted ntfs because it’s a general purpose sneaker-net drive.
Wanting to do my homework and see if this problem has been reported already, I searched the bug tracker. I came across bug #10101. Reading the comments gives the distinct impression that package management zealotry has run amuck (especially where ~/home/config is concerned), and that the prevailing attitude is essentially “package management is the future and if you don’t love it and use it for every little thing, then you’re in the wrong.” The “invalid” status the bug was closed with does nothing to diminish this impression.
The idea of package managers is nice, but the way it’s currently designed and implemented in Haiku is bad, because it’s pretty apparent that it only considers and caters to the case of software products/projects from outside sources. As a result, it runs roughshod over users who are simply making small-scale changes to their personal computing environment to customize it to their own liking. Expecting users to use package management for things like their own shell scripts is entirely unreasonable. It imposes a needless burden on such use cases, especially when those shell scripts are likely to be tweaked and updated very frequently, very unlike software built and intended for mass distribution.
Haiku says its focus is on Personal Computing, which creates the very reasonable expectation that we users can tweak and adapt our systems to enhance whatever way of working suits us best as individual users. But the way things are now, Haiku users seem to be conceptualized as either simple consumers of mass distributed software, or producers of mass distributed software, with only cursory acknowledgement given to the truly Personal Computer user.
My statement was neither aggression nor was it preemptive. I simply emphatically pointed out that it’s very bad, and that a user finds it completely unacceptable. My statement is entirely appropriate. Consider what I encountered above while looking into this problem, along with Haiku not copying files it was told to copy without so much as an “I’m sorry, I couldn’t do what you wanted me to.”, and you’ll have an idea of where I’m coming from and why I said what I said.
Your response to my statement has only confirmed and reinforced my impression of the situation. From where I’m standing, it is you who has responded with undeserved aggression (which is exactly what your false accusation of aggression is), apparently to delegitimize my complaint. You owe me an apology, humdinger.
Could it also be USB/NTFS related? Why don’t you provide a snapshot of the kernel panic?
Do kernel panic snapshots get saved somewhere? I just looked through the syslog files in /system/var/log, and I didn’t see anything that looked obviously like a kernel panic.
No, one needs to take a picture on real hardware, or a screenshot on emulation.
OK. In that case I’ll have to make some fresh backups before I make my system crash. Better safe than sorry. Given how long backing up takes, it’ll probably be late this afternoon or this evening before I can get one and upload it.
As I couldn’t reproduce with a BFS volume, and given the poor state of Haiku’s NTFS driver, it looks like it’s not related to package management.
On the contrary, that’s what the “non-packaged” hierarchy is for.
non-packaged/bin/ works perfectly well for scripts. It’s in the system’s PATH.
I let others decide if my initial suspicion of “pre-emptive” aggression was proven by your later posts.
FWIW I am in full agreement with @humdinger here; the “pre-emptive” comment seems an entirely fair remark, and HaikuWarrior the one who is being needlessly aggressive here.
Also, yes, there are a variety of NTFS KDLs floating around. If I had more time, I’d probably completely rewrite that driver from scratch to be based on the ntfs3g-fuse code; but alas that I do not…
I agree with @humdinger, @korli, and @waddlesplash. It’s more than likely a NTFS problem, as I haven’t encountered this issue on BeFS. Maybe try doing the same copy on BeFS and see if the kernel panic happens again?
I have also encountered kernel panics, mainly when trying to delete files in NTFS partitions in thumb drives.
Like I said before, my statement was neither “preemptive” nor “aggressive”. Expressing annoyance and disapproval of something is not aggression, and responding to a group’s prior behavior (such as the attitude displayed in the comments for #10101) cannot be preemptive. But making false accusations to disparage and defame someone, such as what humdinger and now waddlesplash have done to me, certainly is both of those things. Any honest person would admit that.
Only until someone wants to back up their scripts along with the rest of their home folder. Then Haiku ignores what the user wants to do and doesn’t report its failure to the user. It’s as if someone doesn’t think there should be any warnings when a user does something involving /home/config (bugs 10123 & 11183). Because when someone dares to say there should be, they immediately get attacked with false accusations.
To anyone else reading this: Isn’t it interesting that they’re conspicuously ignoring Haiku’s very repeatable and inexcusably-silent failure to copy /home/config?
I’m done trying to help this project. The trolls running it don’t deserve anyone’s help or support in any form.
I think you are mixing two issues that is not related. There is an knowed bug in the NTFS driver that causes kernel panic when deleting several files in a NTFS partition. This is not related to the Package system or the /home/config itself.
Here is some ticket related to the issue:
https://dev.haiku-os.org/ticket/11407
If you want to share information between Haiku and another system, I would suggest to use a partition or USB drive in FAT32, and previously compress the /home folder in a zip file, to preserve the extended attributes.
The post I commented on didn’t mention anything about #10101, so I couldn’t have known that the discussion there has aggravated you so.
False accusations, disparage, defame, the project running roughshot over users, package management zealotry has run amuck… Don’t you think you’re make quite a mountain of a molehill here?
As said before, the not-copying stuff seems to be related to the NTFS driver, and not a general bug or feature of package management. You may want to reread bugs #10123 and 11183.
#10123 has been closed, pointing to #11183 which is related insofar, as it asks to remove no longer needed alerts. Actually, whats described specifically in #10123 is fixed, because you cannot rename folders like “packaged” or “non-packaged” any more.
I’m sorry you feel that way, but think you’re overreacting.
Wrong. Only the kernel panic requires an ntfs disk. You fixated on the kernel panic from the start.
Whether the destination is bfs or ntfs doesn’t matter. Copying /home/config fails silently regardless:
And I stand by everything I’ve said.
You originally said copying folders inside ~/config fails. So that’s what I have tested by copying ~/config/non-packaged which works.
However, when I do it like you describe now, i.e. drag’n’drop the ~/config folder I see same result: nothing’s copied and there’s just an empty “config” folder at the destination.
Sounds like a new ticket for the bugtracker.
re-read the topic title and the very first sentence carefully.
@humdinger: I tried the same, using the Tracker and Midnight Commander.
Using the Tracker, I had the same issue. But using Midnight Commander, apparently they do the copy (still they warn me that some files cannot be copied)
Maybe is a Tracker issue?
The first sentence (bolding by me):
Topic titles are often shortened, so I took the actual post to be the more detailed description. I then described how I tried to reproduce by copying the “non-packaged” folder. You could’ve stepped in to tell me to try the whole “config” folder instead…
Anyway, this is a bug that should be filed.
Maybe. I, too, get a warning from MC about a “special file” that cannot be created (“kdeinit5_”), but a query doesn’t find such a file…