Page 3 of 20 FirstFirst 1234567813 ... LastLast
Results 41 to 60 of 400
  1. #41  
    Quote Originally Posted by xorg View Post
    ...
    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.
    Ooops. My bad. What was, until just a few days ago, a minor minor irritant turned into big annoyance for me as I got more and more "unable to install messages". What finally tipped it completely for me was Palm not addressing this with 1.2 (as I hoped they would). At that point, I started letting folks know about this. It's worked very well for me, so I've been letting folks know.

    I think it's good to see the script getting some meat on the bones. Twice now, I've gone to the WebOS Internals site to make suggestions, only to find that they've recently been done (the hidden directory and "list" options). I think you guys are doing great work!
  2. #42  
    Hah, I remember this had to be done on my ipod touch.. pressed a button and it moved my apps/ringtones/music in early stages of jailbreaking :P

    Lets see a webOS app for it!
  3. #43  
    Quote Originally Posted by xorg View Post
    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.
    Sweet. Now it actually makes sense to me. Unless you have any objections, I'm going to rename the ORG and DEST to VAR and MEDIA. Makes more sense since they are hard coded anyways. I also added a clean function which removes the directories and symlinks.

    @hparsons Thanks!

    Updated wiki per changes and additions..
  4. xorg's Avatar
    Posts
    633 Posts
    Global Posts
    1,010 Global Posts
       #44  
    ^Cool. Looks good. I might add a few validation mods to your code - thanks for the contribution.
  5. #45  
    Appreciate the corrections...

    You know, here is another thought.. and if a poll needs to be created then so be it:

    If you change /etc/palm/luna.conf to include "/media/internal/.apps" in the app path, you can just move the apps. Then you don't have to link them.

    Doing it that way removes a few steps.. not sure what is better till 1.3? or whatever other solution will fix this issue, but its a thought.

    Ideas/Feedback anyone?
  6. plee3ac's Avatar
    Posts
    109 Posts
    Global Posts
    115 Global Posts
    #46  
    Perhaps for another version for the "unlink" command, the "link" command can also create a full backup of the app (.tgz) which will contain the full permissions and any symbolic links that will be lost when copying the app to the /media/internal/.apps directory. That way if we find that the app does not run correctly from the linked version on /media/internal/.apps, the "unlink" command can restore it fully to /var with no loss of data or attributes.
  7. xorg's Avatar
    Posts
    633 Posts
    Global Posts
    1,010 Global Posts
       #47  
    Quote Originally Posted by daventx View Post
    Appreciate the corrections...

    You know, here is another thought.. and if a poll needs to be created then so be it:

    If you change /etc/palm/luna.conf to include "/media/internal/.apps" in the app path, you can just move the apps. Then you don't have to link them.
    I proposed this a few weeks ago and tried it but it has problems. Some apps are apparently hard coded to reference /var. The link resolves this because the app still thinks it is in /var.
  8. xorg's Avatar
    Posts
    633 Posts
    Global Posts
    1,010 Global Posts
       #48  
    Quote Originally Posted by plee3 View Post
    Perhaps for another version for the "unlink" command, the "link" command can also create a full backup of the app (.tgz) which will contain the full permissions and any symbolic links that will be lost when copying the app to the /media/internal/.apps directory. That way if we find that the app does not run correctly from the linked version on /media/internal/.apps, the "unlink" command can restore it fully to /var with no loss of data or attributes.
    Yea, we discussed this on the last page. I'm thinking of adding a tar backup option. Really the best way to restore is to remove from the Pre GUI and reinstall the app from the respective App Catalog/Homebrew app installer.
  9. #49  
    Quote Originally Posted by xorg View Post
    I proposed this a few weeks ago and tried it but it has problems. Some apps are apparently hard coded to reference /var. The link resolves this because the app still thinks it is in /var.
    ahhh.. well ain't that a pain.

    i just randomly install 77 apps on the emulator..

    Most of the time the permissions are as follows:

    folders rwxr-xr-x
    files rw-r--r--

    However, there are some apps, that install all files/folders at the same permissions. So obviously the ipkg is doing this.

    com.palm.app.timepiece - All rwx------
    de.umass.comics - All rwxrwxrwx

    Weird ****
  10. #50  
    Quote Originally Posted by xorg View Post
    Yea, we discussed this on the last page. I'm thinking of adding a tar backup option. Really the best way to restore is to remove from the Pre GUI and reinstall the app from the respective App Catalog/Homebrew app installer.
    My personal opinion is that doing the TAR backup sounds good on the surface, but I think it's "majoring in a minor", meaning the system would be doing a lot extra (both in functionality and in used storage space) to fix what is probably a very unlikely problem (I haven't heard from anyone yet that actually had the problem...)

    I think the better option is not to worry about it, and uninstall the app and reinstall if the problem crops up with a particular app.
  11. #51  
    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. 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.
    I just want to voice my support for xorg's idea about all homebrew app installers choosing a "no-conflict" install method; that is, homebrew installers should install homebrew apps in such a way that it doesn't interfere with the /var/usr/apps limit imposed by Palm which affects Palm's App Catalog.

    It doesn't solve the problem by any means, but at least it leaves Palm to deal with their own problem and lets the rest of us enjoy ourselves just a little bit more in the meantime. Plus it MAY be a permanently workable solution (except perhaps for an occasional leapfrog-fix when Palm comes out with new updates that break our hack).

    Let Homebrew be Homebrew. Let Official be Official. Let them live in their own space.

    Note to Palm: Want to make everyone happy AND go yet another step in proving you're not evil like those OTHER smartphone builders? Give us our own playground in a future release! Hey -- I had to ask.
  12. xorg's Avatar
    Posts
    633 Posts
    Global Posts
    1,010 Global Posts
       #52  
    ^Thanks for your support.

    Separately, I've updated post 1 with a way to paste the code without using an editor. This should allow those who are able to get to root use the code, but not have to know vi editor.
  13. #53  
    Been watching the stuff you've been adding to the wiki also, good updates!

    One slight thing that may or may not be worth mentioning... should it /opt/bin/mkapp ?

    Since the /opt/ area is supposed to remain untouched per updates.. ?

    In the end it doesn't really matter, as mvapp will run outta both areas.
  14. xorg's Avatar
    Posts
    633 Posts
    Global Posts
    1,010 Global Posts
       #54  
    If I recall, /opt/bin is not on default webOS until you load optware. For this script to be used for those who did not load optware, /usr/bin works out for now. This is intended to be ported as a webOS app anyroad, not maintain as a script.

    Any mojo developers interested in porting this script (or the symbolic link concept) to a webOS App Manager app or incorporate into PreWare? I'm a linux systems coder (in a previous life), not a java developer - would otherwise do it myself.
  15. xorg's Avatar
    Posts
    633 Posts
    Global Posts
    1,010 Global Posts
       #55  
    I've added a feature to bulk move apps. It shows largest app first then asks if you want to move/link. Repeats until you quit.

    This makes it easier to move apps within the Terminal app directly on Pre.

    Usage: mvapp bulkmv - move/link bulk apps

    I recommend avoiding webosinternal apps, linux patches, or apps that store important data. If you move an app that doesn't work any more, first remove from the Pre launcher. If that doesn't work, then use the 'clean' command in mvapp.

    Please post here if you find an app that does not work when linked.
  16. vreihen's Avatar
    Posts
    495 Posts
    Global Posts
    506 Global Posts
    #56  
    Can I ask one question that I haven't seen answered in this thread yet? Has anyone considered creating a replacement Linux filesystem as a huge static-sized file stored on /media/internal as a FAT file, which can be easily mounted as a loopback filesystem where WebOS already looks for user-installed apps? (/var/usr/apps?)

    By throwing a loopback filesystem onto /media/internal, users can back up their installed apps by simply copying the raw file to their PC via USB mode.

    By using a loopback filesystem, users won't be able to poke around inside the loopback filesystem via USB mode...at least from Windows PC's.

    By using a loopback filesystem, you won't lose the file/directory permissions or execute attributes.

    Other than now knowing how the kernel will respond when USB mode is enables and it loses connectivity to the loopback file stored on /media/internal , this seems like the proper fix versus moving application files into the FAT filesystem.

    I'm too lazy to look at my Pre right now, but seem to recall that the /var filesystem was 256 megs. What say we create a 2 gig loopback file named "my_applications" on /media/internal, copy our apps from /var onto it, and mount it under /var/user/apps or wherever the apps are currently stored?

    # mount -o loop /media/internal/my_applications /var/usr/apps

    Was this idea dismissed before with a reason that I haven't seen, or is this the first time it's being brought up?????
  17. xorg's Avatar
    Posts
    633 Posts
    Global Posts
    1,010 Global Posts
       #57  
    This hasn't popped up yet. Loopback from one dir to another has, but not to a virtual file. That is a good idea and the base os does have the 'losetup' command to do it. I like this idea more than resizing /var. As you pointed out, I wonder how it would behave when /media is USB mounted on a computer. Will the loopbackfs still be mounted cleanly? Will it even allow USB mounting to work?

    I did experiment with linking and mounting the entire /var/palm/usr/application over to /media but it still has the FAT fs issue. Thought it would be less risky to move one app at a time than to assume all would be OK on /media. One advantage of sharing with the FAT fs is that you don't have to set any static size, it dynamically shares the fs.

    It comes down to which method has the least risk.

    One advantage of the symbolic link method is that it could separate homebrew apps from Palm approved apps. When forcing all /var apps to another non-Palm solution, it puts Palm approved apps at risk. At least with the symbolic link method proposed, you can choose on the fly if it uses physical /var or the symbolic link. The loopback to virtual file may be a better option if it's stable.


    Here is a way to do the loopfs if someone wants to tinker with it. I haven't tested this yet. And there are other ways to create...

    # create a 512MB filesystem (or change 'count' to what you want, 1024000 for 1GB)
    dd if=/dev/zero of=/media/internal/virtualapps bs=1024 count=512000

    losetup /dev/loop0 /media/internal/virtualapps
    echo $? #should return 0 if successful

    mkfs -t ext3 -m 1 -v /dev/loop0

    mv /var/usr/palm/applications /var/usr/palm/applications.save
    mkdir /var/usr/palm/applications
    mount -t ext3 /dev/loop0 /var/usr/palm/applications
    cp -r /var/usr/palm/applications.save/* /var/usr/palm/applications

    #test everything is OK, might want to tarball this directory before removing.
    rm -r /var/usr/palm/applications.save

    Use at your own risk. Haven't tested the above yet.

    It would also have to be added in /etc/fstab to mount at bootup.

    This is worth researching further. I'm going to tinker with it myself and may swing my support for this option if it turns out to be cleaner. In the meantime, the symbolic link method is a doable solution for now.
  18. vreihen's Avatar
    Posts
    495 Posts
    Global Posts
    506 Global Posts
    #58  
    My thinking is that Palm painted themselves into a corner with the initial disk partitions, and I bet that there are numerous discussions going on at Palm HQ about how to re-size the internal partitions via the update process without whacking the user's contents of /media/internal .

    Since their sales literature advertises 7.? gigs free to hold your music and files, it will be hard for them to reduce that amount via an update without raising holy heck with some users because it was promised in the glossies. (Even worse than giving up on iTunes compatibility.) Making users have to back up their Pre's /media/internal onto their PC before re-partitioning is likewise not going to be popular.

    My thought for getting out of this pickle is to add a dialog to the Pre on first boot, saying that your internal storage capacity is 7.? gigs and asking you how much of that space you wish to set aside for applications storage. That would be the size of the loopback filesystem that it creates. In an ideal world, they could use LVM to make it expandable in the future, but I'm not sure that the LVM tools are on the Pre right now. By making the user choose their app partition size, users can't complain about it taking up space on their USB-visible partition since they opted to do it on first boot. I'd throw out 2 gigs as a suggested default, which is 8 times the current size of /var .

    Developers of the homebrew app installers can offer a similar service to build a loopback file and move the existing programs onto it, using the same type of dialog to let users choose how much music space they want to sacrifice for app storage. Heck, for all I know, some programmer at Palm might be reading this right now and adding the concept to their release roadmap for WebOS 1.3 or 2.0 as the official fix.

    The only gotcha is the USB mode disconnecting /media/internal whenever you're transferring files or music. If the loopback file survives the partition being disconnected, we're golden. If not, perhaps we can look at replacing the USB access scheme with something that will allow the /media/internal partition to be shared between an external PC and the Pre's kernel.....
  19. xorg's Avatar
    Posts
    633 Posts
    Global Posts
    1,010 Global Posts
       #59  
    Quote Originally Posted by vreihen View Post
    The only gotcha is the USB mode disconnecting /media/internal whenever you're transferring files or music. If the loopback file survives the partition being disconnected, we're golden. If not, perhaps we can look at replacing the USB access scheme with something that will allow the /media/internal partition to be shared between an external PC and the Pre's kernel.....
    I was thinking the exact same thing. Palm needs to virtualize the driver for /media partition so that it can be mounted by USB mount and kernel simultaneously, sorta like both of them doing an nfs mount type thing. This could resolve lots of issues and a long term strategy for storage management could be much more easily developed. Scaled down LVM too would solve storage mgmt issues. Listening Palm?

    I'll tinker with the loopback virtual file method this week. Hopefully it works well after USB mounting. I'm still a little uncomfortable about moving all of /var apps to a non-Palm solution - with the symlink method, users can choose on a per app basis with an easy backout plan. But let's see where loopback fs goes. It really could be the optimal solution.
  20. #60  
    @xorg

    If you need any help with testing... just tell me. I'm not great at linux.. but i'll usually figure things out.

    I'm pretty sure you've seen this.. but Tutorials Linux opt on loopback - WebOS Internals goes into the USB disconnecting / connecting issue
Page 3 of 20 FirstFirst 1234567813 ... LastLast

Posting Permissions