#1533 closed enhancement (invalid)
forcerm
| Reported by: | kvdman | Owned by: | axeld |
|---|---|---|---|
| Priority: | normal | Milestone: | R1 |
| Component: | File Systems/BFS | Version: | R1/pre-alpha1 |
| Keywords: | Cc: | ||
| Blocked By: | Blocking: | ||
| Platform: | All |
Description
I believe forcerm was part of R5. Anyways, I somehow ended up with a folder that contained some files in it that I couldn't delete off the disk... an enhancement to allow force delete would be good, or perhaps there's another way in Haiku I'm unaware of.
Change History (14)
follow-up: 2 comment:1 by , 17 years ago
comment:2 by , 17 years ago
Replying to umccullough:
Isn't that what rm -rf is for?
Perhaps I'm ignorant - I looked up the definition of -f and it seems to simply not prompt, and ignore missing files...
So I can't find any documentation on what forcerm actually did other than "removes stubborn files" :)
comment:3 by , 17 years ago
Oh, well yes, that's exactly what I wanted. Removing stubborn files. Wasn't there a key combination for force delete?
comment:4 by , 17 years ago
follow-up: 8 comment:5 by , 17 years ago
| Resolution: | → invalid |
|---|---|
| Status: | new → closed |
"forcerm" is a work-around for a bug in the original BFS implementation. It does not apply to Haiku's BFS. If you somehow manage to create files that you can't delete, then please tell me how you did it, or please make an image available - and open another bug report for that :)
comment:6 by , 17 years ago
I'm not sure I could replicate the problem, but I had a lot of cache in Opera's temp directory, and I tried deleting the contents, but tracker got stuck about 40% of the way through, after waiting about 10 min. I reset the system. Upon reboot, I threw the entire folder in the trash, but when I tried to empty it, it gave an error that it couldn't delete some of the files. Upon checking the contents of that folder, the files weren't in there anymore, but tracker still gave the warnings for the specific files it can't delete. Actually I still have the disk image the problem is on, would you like it?
follow-up: 9 comment:8 by , 17 years ago
Replying to axeld:
"forcerm" is a work-around for a bug in the original BFS implementation. It does not apply to Haiku's BFS.
I was thinking something like that when I read the definition on betips...
If anything else, the (inevitable) Haiku version of chkbfs should be able to fix any and all known issues like this right?
comment:9 by , 17 years ago
Replying to umccullough:
If anything else, the (inevitable) Haiku version of chkbfs should be able to fix any and all known issues like this right?
Exactly - unlike forcerm, chkbfs is unfortunately implicit with the design of BFS. It will be part of Haiku as well.
follow-up: 14 comment:10 by , 17 years ago
try unzipping this folder and then sending it to the trash and deleting it. I may have to send you the disk image if this doesn't work (or if you delete it lol).
http://www.haikuware.com/downloads/Languages.zip
btw, did you get the paypal transfer for the thank you award Axel.
Bye!
comment:11 by , 17 years ago
One question about chkbfs though... say in the case of a normal user, the situation occurs as it did to me. With the befs one talked about elegant and worry-free recoveries after power failures etc. and no check disk like in Windows...
How is the average Joe going to know to run chkbfs from the terminal in order to repair an error in the filesystem/files like this??
thx
comment:12 by , 17 years ago
Sorry, one more comment... OS X has a similar file system, how do they get around this? If there's a dirty unmount, or shutdown, that gets logged right? And then after so many dirty unmounts, their filesystem check gets initiated? Would Haiku have something similar? Isn't their also a file system check when you install system software or updates 'optimizing performance'?
thx
comment:13 by , 17 years ago
With the befs one talked about elegant and worry-free recoveries after power failures etc. and no check disk like in Windows
I've always found that a bit annoying personally... it's just marketing talk. Perhaps it works like that in theory, but low power and power failures can do bad things to hardware which can subsequently do bad things to disks... so it's not a very smart statement. A stick of bad RAM can also cause untold amounts of damage to filesystems...
In any case, the existence of chkbfs, and how it's run are two very separate discussions... once it's written, I suspect the "automation" of running it whenever necessary can be implemented as needed. Perhaps Tracker has some logic that watches for bad situations and alerts the user that they need to run chkbfs (which it will then prompt them for) - that's just details. Ultimately chkbfs must exist - just like every filesystem benefits from some type of consistency-checking utility.
comment:14 by , 17 years ago
Replying to kvdman:
try unzipping this folder and then sending it to the trash and deleting it. I may have to send you the disk image if this doesn't work (or if you delete it lol). http://www.haikuware.com/downloads/Languages.zip
Once you zipped it up and there still is the same problem, it's no BFS bug anymore. In this case, the files were directories, and I could easily delete them (ie. using "rm -rf"). So if that doesn't help on your image, I would need that.
btw, did you get the paypal transfer for the thank you award Axel.
Sure, and thanks!
BTW I've republished the lost newsletter "Why BFS needs chkbfs" as part of my blog: http://haiku-os.org/blog/axeld/2007-10-05/why_bfs_needs_chkbfs
Isn't that what rm -rf is for?