Page 2 of 20 FirstFirst 123456712 ... LastLast
Results 21 to 40 of 400
  1. xorg's Avatar
    Posts
    633 Posts
    Global Posts
    1,010 Global Posts
       #21  
    Quote Originally Posted by rposa View Post
    Why not just
    1) Make a .hidden directory in the /media/internal
    2) remount /media/internal/.hidden as /var/usr/palm/applications
    I tried that and also tried just doing a symbolic link on entire app dir. I posted that as an option originally but removed it. It generally worked, but then realized that files lose their file attributes when moved to FAT filesystem. If there is an app that relies on the file attributes (such as execution bit), it may not work. The single app move method allows you to keep some apps on /var if needed. I don't think it's wise to force all apps to the FAT fs. Worth testing more though.
  2. #22  
    Quote Originally Posted by astrobill View Post
    Um...nice, but are you guys serious? I mean....this helps the 0.00000001% of Pre users who are willing to learn Unix shell programming and Linux to fix their Pre's with their own customized scripts...LOL.

    This is great for developers or programmers who want to learn how to program this thing, but come on...really.
    The script is written. No one has to program anything. Not sure I follow you.

    As a matter of fact, with the latest script, you don't even have to create the directory. The script creates it the first time for you.
  3. xorg's Avatar
    Posts
    633 Posts
    Global Posts
    1,010 Global Posts
       #23  
    Quote Originally Posted by hparsons View Post
    I'm not 100% sure (but pretty close), but looking at your script, I believe:
    I changed the code on WebOS-Internals as well.
    ^That doesn't work for me. I changed a couple things, try again.
  4. #24  
    <merged and moved>
    _________________
    aka Gfunkmagic

    Current device: Palm Pre
    Device graveyard: Palm Vx, Cassiopeia E100, LG Phenom HPC, Palm M515, Treo 300, Treo 600, Treo 650, Treo 700p, Axim X50v, Treo 800w



    Please don't PM me about my avatar. For more info go here.

    Restore your Pre to factory settings using webos doctor and follow these instructions
  5. #25  
    Quote Originally Posted by astrobill View Post
    Um...nice, but are you guys serious? I mean....this helps the 0.00000001% of Pre users who are willing to learn Unix shell programming and Linux to fix their Pre's with their own customized scripts...LOL.

    This is great for developers or programmers who want to learn how to program this thing, but come on...really.
    I'm not sure you understood all of the other posts in the thread (which might be like "looking for a needle in a haystack" for a non-coder, so I understand and I'm not criticizing you).

    It was clear to me that the initial post indicated that we want to eventually make this something that the homebrew installer tools will eventually do automatically:

    Quote Originally Posted by xorg View Post
    ... It's unfortunate that Palm has not resolved the issue in the 1.2 update. ..., but this needs support by the homebrew community to add in the homebrew installer apps.
    Prior to your post, Jason made it very clear that he's working on rolling the feature into his WebOS Quick Install tool (while still cautioning that the idea might cause problems with future Palm updates, hence reason he is calling the feature "experimental":
    Quote Originally Posted by Jason Robitaille View Post
    xorg,

    Just wanted to mention, a future version of WebOSQuickInstall will be including the experimental memory resizing or /var/ (though in the process would wipe /media/internal/ so ppl would need to backup those files first). People have reported success, though I have been told by Chuq that it's very possible a future update would cause issues (leading me to believe Palm is taking this issue more seriously now that the app catalog is growing more.
    So have faith that an automated way of resizing the partitions (as well as a WebOSQuickInstall that works with the official 1.2.0) should hit the "shelves" tomorrow for your downloading pleasure.

    Please don't take Jason's caution lightly, If/when palm comes up with an update that resizes the partitions, you'll want to wait until other have tried the update without un-resizing their partitions. If this feature breaks future updates, let more knowledgeable people deal with the issue rather than getting yourself in a bind. For now, just keep in mind that you might have to set the partition back if a future update does not work with this resize feature, That might mean deleting apps to get back down to the old size. Personally I don't think we will have all that pain, but I'd want you to mentally prepare yourself for it before you decide to try out this very useful resize feature.

    astrobill, I hope you (and others) find these comments/suggestions helpful.
    Last edited by sudoer; 10/01/2009 at 08:10 AM. Reason: fixed some typos
    I'm both super! ... and a doer!
  6. xorg's Avatar
    Posts
    633 Posts
    Global Posts
    1,010 Global Posts
       #26  
    ^yea, this is just in a proof of concept phase right now, not consumer ready yet. This is a developer forum afterall, not production homebrew forum.

    This symbolic link method or other methods will eventually need to make it into the homebrew installer managers to deal with the issue.

    Methinks the mitigation to risk and contingency backout of the link method is easier to deal with than other proposed methods, so I'm pushing for the link method at the moment until something better comes along. Resizing /var is worth pursuing if the issues could be worked out. The risks sound higher for resizing than the link method at this time.

    If others comfortable with Linux could test the script in post 1, please help out and post your results. Thanks.


    Edit: Have thought more about merits of link method and resizing /var. One challenge with resizing /var is that it will still have a fixed static limit - how do you decide how much to increase it. The link method allows to dynamically use the usb partition, so there is no need to set a specific size dedicated to apps. If usb drive is filled, users could simply remove some media if they need more app space.
    Last edited by xorg; 10/01/2009 at 11:38 AM.
  7. #27  
    I added this after the: cd $ORG

    Code:
    if [ $APP == "list" ]
    then
      du -s $ORG/* | sort -n
      exit
    fi
    So if you just type in: mvapp list
    It'll list the apps and sizes

    Makes it a little easier instead of having to remember the command to list the apps.
  8. xorg's Avatar
    Posts
    633 Posts
    Global Posts
    1,010 Global Posts
       #28  
    ^Good idea. I've added it.
  9. #29  
    Someone may also wanna update the wiki..

    Its got a different info then this post.
  10. Scottyd's Avatar
    Posts
    8 Posts
    Global Posts
    17 Global Posts
    #30  
    This may be a shot in the dark. But does anyone really think that Palm will put download limits on apps when they are trying to make money on them?

    I figure that once that pay app catalog is up tomorrow. So will a small update to fix the install limit problem. That day or soon after.

    It would be really stupid and literally a waste of money not to change this ASAP! Not to mention all the people who want to submit pay apps to sell through the catalog. Why bother if people can't even download the damn things?

    Just my 2 cents.
  11. #31  
    I agree completely, but currently the only solution is a) do something like this script either moving or linking applications OR b) doing a lvm resize as mentioned in other posts. So the simpler solution is this. The lvm resizing hasn't been mentioned alot so i'd rather do something temporary until the lvm resizing is THE solution to do.
  12. xorg's Avatar
    Posts
    633 Posts
    Global Posts
    1,010 Global Posts
       #32  
    I think the only tactical thing Palm could do until another major release is change the limit size to install apps on the existing /var. They could bump the limit up another 25MB to maybe 50MB. If they were going to make changes, you'd think it would have been done with the 1.2 update.

    The Homebrew Community somewhat created part of the problem so needs to come up with their own solution. I would go as far as to propose that all Homebrew apps _should_ be moved with a link to /media/internal by default and physically use /var only if needed. The developer could put a flag file in the package (or some method during submission) to determine if it is OK to run linked to /media or if it specifically needs to physically be on /var. The homebrew installer apps could then automatically do the move/link if the packaged is flagged for it.
  13. #33  
    To xorg, i see you rewriting and changing stuff as im messing around and changing things.. so here is what i've done. If does listing, linking and unlinking.

    Code:
    #!/bin/sh
    
    # This code is open for re-use with no restrictions.  xVAR
    
    # Usage: mvapp list - list all apps sorted by size
    # Usage: mvapp link com.org.appname - move app from var to media
    # Usage: mvapp unlink com.org.appname - move app from media to var
    
    COMMAND=$1
    APP=$2
    # can change destination to anything you want, but use a leading . - props to emoney_33
    MEDIA=/media/internal/.applications
    VAR=/var/usr/palm/applications
    
    cd $VAR
    
    # list app directory with size, props to daventx
    if [ $COMMAND = "list" ]
    then
      du -s $VAR/* | sort -n
      exit 0
    fi
    
    if [ $COMMAND = "link" ]
      then
      if [ -d $MEDIA ]
      then
        echo "Directory exists..."
      else
        mkdir $MEDIA
      fi
      if [ -h $APP ]
      then
        echo "Link already exists for... ${APP}"
        exit 1
      fi
      if [ -d $APP ]
      then
        echo "Moving $APP to $MEDIA..."
      else
        echo 
        echo $APP "is not a valid application directory."
        echo "Usage: mvapp list"
        echo "Usage: mvapp link com.org.appname"
        echo "Usage: mvapp unlink com.org.appname"
        exit 2
      fi
      COMMAND=linktrue
    fi
    
    if [ $COMMAND = "unlink" ]
      then
      if [ -d $APP ]
      then
        echo "Moving $APP to $ORIG..."
      else
        echo 
        echo $APP "is not a valid application directory."
        echo "Usage: mvapp list"
        echo "Usage: mvapp link com.org.appname"
        echo "Usage: mvapp unlink com.org.appname"
        exit 2
      fi
      COMMAND=unlinktrue
    fi
    
    ## link
    if [ $COMMAND = "linktrue" ]
    then
      mount -o remount,rw /
    
      echo "Size of $VAR before move... "
      du -sh $VAR
    
      # move over to USB drive
      cp -r  $VAR/$APP $MEDIA
      if [ $? != 0 ]
      then
        echo "Copy failed. Leaving app in $VAR."
        exit 3
      fi
      rm -r $VAR/$APP
      if [ $? != 0 ]
      then
        echo "Remove failed. Leaving app in $VAR."
        rm -r $MEDIA/$APP
        exit 4
      fi
      # create the symbolic link
      ln -s $MEDIA/$APP $VAR/$APP
      echo "$APP moved and linked."
    
      # rescan luna in case it's needed
      luna-send -n 1 palm://com.palm.applicationManager/rescan {}
    
      echo "Size of $VAR after move... "
      du -sh $VAR
      exit 0
    fi
    
    ## unlink
    if [ $COMMAND = "unlinktrue" ]
    then
      mount -o remount,rw /
    
      echo "Size of $VAR before move... "
      du -sh $VAR
    
      # remove symbolic link
      rm -r $VAR/$APP
      if [ $? != 0 ]
      then
        echo "Remove symbolic link failed. Leaving app in $MEDIA."
        exit 4
      fi
      # move over to USB drive
      cp -r  $MEDIA/$APP $VAR
      if [ $? != 0 ]
      then
        echo "Copy failed. Leaving app in $MEDIA."
        exit 3
      fi
      # sucessful unlinking
      rm -r $MEDIA/$APP
      echo "$APP moved and unlinked."
    
      # rescan luna in case it's needed
      luna-send -n 1 palm://com.palm.applicationManager/rescan {}
    
      echo "Size of $VAR after move... "
      du -sh $VAR
      exit 0
    fi
    
    echo $COMMAND is "not a valid command."
    echo "Usage: mvapp list"
    echo "Usage: mvapp link com.org.appname"
    echo "Usage: mvapp unlink com.org.appname"
    exit 0
    I see you're using case now, while mine still uses if/fi. I could never for the life of me find how to do an AND, just an OR (-o). Never even found a list of what -h and -d do either. I'll have to read up on some more on it.

    Obviously im just a hack at shell programming... but you get the general idea, and it does work.
    Last edited by daventx; 10/02/2009 at 10:26 AM. Reason: changes
  14. #34  
    Quote Originally Posted by xorg View Post
    ... The Homebrew Community somewhat created part of the problem so needs to come up with their own solution. ...
    Actually (as I see it at least) the problem would still exist in the absence of Homebrew. A person without any homebrew apps would eventually reach the limit by leaving email on their device and installing app store apps. We just helped expose the problem sooner by making more apps available sooner. Palm has to come up with a solution to what is really their problem. Homebrew can devise workarounds (as described in this thread and by you) in the meantime.
    I'm both super! ... and a doer!
  15. xorg's Avatar
    Posts
    633 Posts
    Global Posts
    1,010 Global Posts
       #35  
    ^Yea, I was reluctant to phrase it that way. I do think the homebrew community could address this in a way that is independent or doesn't interfere with Palm. Perhaps homebrew should not be located on /var unless necessary.
  16. xorg's Avatar
    Posts
    633 Posts
    Global Posts
    1,010 Global Posts
       #36  
    Quote Originally Posted by daventx View Post
    To xorg, i see you rewriting and changing stuff as im messing around and changing things.. so here is what i've done. If does listing, linking and unlinking.

    .
    I've been thinking about how to address 'undoing'...

    1) Move apps back from /media as you are pursuing. Problem is, the file attributes were lost on the first move. If you are moving back, it's could be because it didn't work due to attributes.

    2) Backup the original with tar to /media. It keeps the attributes when you restore. But it doubles the space on /media to move an app.

    3) Just let the user reinstall the app if there are problems. This is probably the cleanest way to do it.

    What you think?
  17. #37  
    1) I looked at the permissions, i don't think it'll be as much of an issues as you think.. except for random apps. Those then could have the "Install on var" flag you mentioned above, if this even becomes a long time solution.

    If the first move screwed the app, then "unlink", uninstall then reinstall. Which is still the process from the original script if something goes wrong. So why change it...

    2) The only problem i could foresee with that is if the app is actually using a db or xml or something for data. So now when you unlink, you just wrote over everything you did. Unless you extract the tar, then overwrite with the /media files? Would that keep the permissions?

    3) Agreed.

    I'd like to see someone just create a gui frontend for this.. It'd be almost the same as "software list" under "device info"
    Last edited by daventx; 10/02/2009 at 11:46 AM. Reason: cause
  18. xorg's Avatar
    Posts
    633 Posts
    Global Posts
    1,010 Global Posts
       #38  
    The webosinternals script is open to anyone to update it so I think any ideas should be posted in that script. If there are multiple people writing their own routines, I'd like to restructure the script to use 'function calls' (instead of a bunch of if statements). Give me some time to restructure it before posting your updates.

    I didn't really intend for this script to go into production so am reluctant to really mature it. It's just a proof of concept. Ideally someone would port to javascript. I'm a Linux head, not a java dude so am hoping the concepts get ported to PreWare, etc. or someone writes an independent webOS app to manage moving the apps.
  19. #39  
    I completely understand what you mean. Originally i was just adding the "list" feature to make it easier.

    I swore you had written something about bash? And function call limitations with sh.. I was just going to mention its available through the opt packages, and even though preware on the phone.

    Well, either way.. if more people start bugging on this thread about having the list, link, unlink.. maybe more people will get involved. Just wanted to share what i had done.
  20. xorg's Avatar
    Posts
    633 Posts
    Global Posts
    1,010 Global Posts
       #40  
    I realized sh does support function calls so removed comment (I'm used to bash style, which didn't work). I've posted on webosinternals a restructuring of the script to use function calls. Should make it easier for others to add their own functions and features. Have at it. Feel free to add your unlink feature in webosinternals.
Page 2 of 20 FirstFirst 123456712 ... LastLast

Posting Permissions