Try opening " UP_DTVES400.lnk" by dragging in and dropping it into an already-open Notepad window. Then copy the text from there into your package Install Command.

For the storage issue: if 50 MB is not a problem, why don't you split this 160 MB package in 4 "chunk-packages" of 40 MB each? make a bundle with these 4 packages. For the lnk: why don't you use the full content of the lnk file as Install Command in Package Builder? For instance, if the lnk contains: XX#\windows\wceload.exe /noui /delete 0 \Storage Card\myinstaller.cab just write "\windows\wceload.exe /noui /delete 0 \Storage Card\myinstaller.cab" (without quotes) in the "Install Command" field. To see what's inside a lnk, just drag&drop it from a PC (not terminal) into Notepad. Do NOT copy the heading XX#.

Telepathy exists indeed, Larry !

Marc; As I understand your issue, it is NOT with importing the Package into MSP, which the answer provided by Mike would address, but rather with MSP refusing to install the Package on the device without complaining about insufficient memory on the device.  Is this correct? If that is correct, then there are two things you can do.  First, you need to understand that for historical reasons, a Package is assumed to be delivering ALL its content to the default destination on the device, which is generally on \Appliation.  The MSP Agent totals up all the files in the Package and errors if there is not enough room on \Application for them.  This goes back to the days when there was generally only one place files could be put on a device.  The Agent has never been extended to figure out ALL the places a given Package might be putting files and total them up separately. So, if you are putting files someplace other than the default destination, such as Storage Card, you should specific Alternate Storage AS that place.  When you specify Alternate Storage, that becomes the ONE place that it checks to see if there is enough space for ALL the files.  Specifying \Temp as Alternate Storage is wrong since it does not have the Agent checking the place you are putting files and hence may help in some cases, but is really a crap shoot.  Specifying \Storage Card as Alternate Storage actually addresses the cause of the problem. Second, the Agent assumes that ALL files will be ADDED to the specified Alternate Storage, but some may overwrite files that are already there.  So, while the Package might fit if some files are being overwritten, the Agent may decide the Package won't fit because there is not room for all the files if they were all NEW.  Since it does the check ONCE up front, it could reject a Package that could have fit.  To deal with this, you could use Adjust Package Size.  You can set that to some negative number (other than -1) and it will cause the check to use a number the specified number of bytes smaller than the actual totalled size of all files.  Or, if you specify -1, then it disables the check altogether.  Keep in mind, however, that if you use this, you are telling the Agent to trust you and the Package may not fit if you give it bad information. Allan

Thanks for the reply. Any suggestions on the best way to luanch a .lnk file on the device using AirBeam. A tried a batch file Install Command: BATCH \Storage Card\DTV.install With this in the batch file: \Storage Card\UP_DTVES400.lnk run \Storage Card\UP_DTVES400.lnk Not sure what it takes to kick off this file.

After testing, I can send 10mb, 27mb and 50mb directly to the SD card, but still not 161mb. I had to define Alternate Storage of \Temp in order for the file to get to the \Storage Card. If there is a better way, please let me know. One other question came up, what is the best way to luanch a .lnk file using AirBeam. Is there a good Install Command or do I need to use a Batch file of some kind?

There is a rough limitation of 100mb.
It is a web timeout issue caused by the size of the file, and depending on the various systems, the timeout will be met with different file sizes. It is not a size storage issue.  A possible work-around is to use the PackagesToInstall folder as a solution for dealing with oversized APF's

Some may then find useful a simple utility I once wrote for a friend TA (I called it axe, because it was inspired in Hacha). There is a PC version and a WM version. Both work the same way. It just splits a given file in a number of sequential files of 2000000 bytes each, whose extension is .axe. This is with -c option. Last file's size is the remainder. Then, with -j option and the first .axe file, it just joins them and recreates the original file. Yes, I know size should be an option, but I wrote it for a specific requirement. Also, deleting the axe files after successful "pasting" should be optional too. If a huge file is to be sent, then first "cut" it on a PC (axePC -c MyFile), then create a package per file with no Install command except last one, which should be "reconstruct" the original file using all the chunks (axeWM -j MyFile000.axe). Should you find this useful, just tell me and I will send it. Source code in perfect Spanish too :).

Hi All, Here is my need:  download on the SDcard a 260MB file For what I understand from the different updates: - The limitation is historically set to 100MB   The suggested solution would be to overcome the problem by creating 6 apf of less than 60 MB. Which is not possible if you want to download a backup of the whole customer environment (OS+ customer applications + customer data). some files are bigger than 65MB. Did I miss something? Will the new MSP 4 allow to create bigger package and allow to transfer bigger files to the SD cards? Thank you for your advises Regards Philippe