Results 1 to 7 of 7
  1. tfj
    tfj is offline
    tfj's Avatar
    36 Posts
    I was snooping around the TP's webOS filesystems (using Xecutah) when I saw a large
    number of "Quake" files (from a dizzying demo) and decided to erase them, with
    "rm -rf <path_to_quake_files>"; this resulted in screenfulls of 'operation not
    permitted' and 'read-only filesystem' messages, and then the TP apparently froze
    (or possibly paused), with no screen or on-off button response, so I held down
    the home and power buttons for 15 seconds, and it went into the hp 'pulsating orb'
    reboot. When things came back up, I noticed the screen image (a flower) was one I hadn't
    seen before, and, all 'Downloads' apps and the few files I had put in /internal/media(?)
    had been erased.

    To prevent this happening in the future, please give a thorough, but not-too-deep description
    of exactly what the 'home/power buttons-press' does, and what may have happened in my case.

    Please note I'm online only once-a-week.
  2. #2  
    Simple explanation - you probably made a typo in the path and wiped your device with the rm command you typed yourself.

    -- Rod
  3. tfj
    tfj is offline
    tfj's Avatar
    36 Posts
    Well, I understand that "rm -rf" is dangerous, and that's possible, but the error pages seemed to be about the Quake files, and paused a few times, so when it paused about ten seconds, and the power button did nothing, I did the 'center/power' buttons reboot; also, it didn't erase everything, but seemed to specifically delete all the downloded apps, and I suspect the few files in /media/internal, so I wonder if there's a risk of triggering the "full erase" by doing a reboot while the TP is semi-stuck on an erasing job.
  4. #4  
    I think what Rod is saying is the path was wrong, so you deleted more than just the Quake files.

    So technically you triggered the erase not the hard reset. Holding down power + center button is akin to shutting down your desktop by holding down the power button. It's not good for it, but shouldn't cause what you have seen. If it were to do anything I would suspect entire corruption or at least corruption/loss of more than just the Media/Internal directory. Did you plug into a PC at any time around this event? And how are you checking Media/Internal for data?

    I have had to hard reset multiple webOS devices.... to this point, have never wiped Media/Internal doing so. This includes even doing battery pulls on some devices.
    I love physical keyboards... but there is two devices that would make me consider a slab, one is something running a full version of Open webOS. The other is an iPhone!!!! HA HA just kidding (about the iPhone that is)...
  5. tfj
    tfj is offline
    tfj's Avatar
    36 Posts
    I tried to replicate the problem on a freshly doctored TP, but nothing untoward occurred, so yes, you are correct: I probably made a wild-card goof, erasing all the app files in the same folder as the quake files; the boot was probably normal, with no erase-mode triggered, and /media/internal may have been untouched after all.

    To give my post some redeeming value, here are some ideas:

    Never run "rm -rf XXX" directly, by itself; instead run "ls -a XXX" first, to see what you are about to demolish. Better yet, wrap such code up in a shell script, named, say, "rmrf", and use it instead.

    I would do the same thing with the "mv" command, which in my experience is the quirkiest and most dangerous command ("mv myfile Myfile"? Oops! "mv oldfolder/* newfolder"? Oh, no!). It's seems prone to mystifying errors, depending on the version and the filesystem. In fact, I would avoid using "mv" anywhere, and instead, use "cp", exist-and-compare tests, and "rm" in a script.
  6. #6  
    Quote Originally Posted by tfj View Post
    Never run "rm -rf XXX" directly, by itself
    Better yet, don't run it at all. Use a graphical file manager if you don't have a handle on Linux commands.
  7. tfj
    tfj is offline
    tfj's Avatar
    36 Posts
    Quote Originally Posted by GMMan View Post
    Better yet, don't run it at all. Use a graphical file manager if you don't have a handle on Linux commands.
    Yes, assuming the authors built in protective logic to make actions like mv *****-proof. Such utilities tend to be limited and inflexible, though, and I usually use a command-line.

    I tested xx.commander and Tegi's commander regarding the command "mv oldfolder/* newfolder" (which, you understand, fails if no directory "newfolder" exists - including the simple case of mistyping, e.g. "nswfolder" - and proceeds to delete every file in "oldfolder" except the last). Due to their visual nature, you are protected from moving anything to a non-existent folder (although there's no wildcard ability that I see). In fact, xx.commander has a "Cmd" shell-like facility, and running "mv oldfolder/* nswfolder" there properly tells you that 'file doesn't exist', so xx.commander apparently uses protective scripting for 'mv'.

    The shell command "mv oldfolder/* newfolder" is too dangerous to use - you're one slip away from disaster - but a lot of people won't know that, since it's a straightforward command (which works fine when everything is in order). For the "mv myfile Myfile" command (or maybe it was vice-versa), apparently, on some vfat filesystems, this fails to create Myfile, but succeeds in deleting myfile. This is too goofy to deal with. I've also had a couple of mystifying cases where an intended "mv file folder" command resulted in "file" being renamed "folder", and all of "folder"'s files vanished. Even if I made a dumb mistake, it shouldn't be so easy. So the suggestion, if you use a command-line, is to avoid using dangerous primitives like rm and mv directly, and use safe checking-scripts instead.

Posting Permissions