HI all,
I'm running into some issues with the latest 4.2 release of the PA.com platform.
First of all, I'm running a lot of portable apps from my server, so the path is \\servername\apps\portableapp
This way it doesn't matter what pc I sitting behind at the house, and it's easily copied to a portable HD for using 'on the road.
Buty here are my 'issues':
First I tried to install PA.com onto the server, but it cannot resolve the UNC path and throws a location error. I just installed on a local HD and moved the files over. Workaround> solved!
Next I moved my portable apps over to the proper folder inside the PA.com install, started the PA.com app and all my apps showed up in the menu. Sweet!
But when I manage my apps, and try to update them, I often get a "The device you have selected to install to does not have enough free space for this app".
Not true as there's Gb's of space available on the server.
If I update manually by DL'ing the latest version and installing it over the 'old' version it works just fine.
But this basically defies the purpose of the updater
So it must be something similar to the PA.com install and UNC path's......?
The list of apps that's not updating is quite long, so here it goes:
7-zip, aMSN, Audacity, Celestia, ClamWin, FileZilla, GIMP, InfraRecorder, jPortable, FireFox, Thunderbird, Opera, Pidgin, PNotes, qBittorent, Stellarium, Task Quach, VirtualDub and VLC.
It might be just the beta status of the menu system, or the apps themselfs, but it would be very nice to have this fixed in some upcoming version.
Any tips are very welcome!
P.S. I checked this on a local install with just a couple of apps, and that does work, so it seems it's a UNC related issue..
thanks!
rob
UNC paths are unsupported. Map a drive letter to it.
Sometimes, the impossible can become possible, if you're awesome!
I was trying to avoid that
Well... if all fails, map it...
I've been using PStart for years, and I assumed PA.com would just work accordingly regarding UNC paths.
Thanks for the quick reply.
rob
None of our apps support running from UNC paths, either. Some old ones not using the PortableApps.com Launcher won't complain immediately, but many of them will still directly fail or break things. The PortableApps.com Launcher avoids this by forbidding UNC paths.
I am a Christian and a developer and moderator here.
“A soft answer turns away wrath, but a harsh word stirs up anger.” – Proverbs 15:1
0) Copied my USB contents to \\allspice\work\tools\portable
1) Ran Start.exe from \\allspice\work\tools\portable
2) Lauched FireFox.
3) Posted this message.
If you can't give us real UNC support how about a cheesy work around.
Start.exe can detect if it's being run from a UNC and map a temporary drive letter. Then when PoratbleAppsPlatform.exe is launched, it is launched using that letter.
Since the mapping is temporary it only lasts for the current session and everything works happy.
The problem with that is that many PortableApps.com apps still don't support directory moving (e.g. from X:\Something to X:\ rather than just Y:\ to X:\). This then raises the question: what would you map the drive as? If you have \\allspice\work\tools\portable, should Z: be mapped to \\allspice\work, \\allspice\work\tools or \\allspice\work\tools\portable? While some cases could be satisfied with this (specifically, those where the whole drive is mapped), not all can: say, for example, that you have that being C:\work\tools\portable; this would require mapping \\allspice\work to Z:\work, which can't be done. Of course, in all this I am assuming that you will not always be running it via a share, or else the behaviour could be made consistent.
For the moment, I think we can leave this as a power user feature (I don't think I've heard of anyone who doesn't know how to map a network drive trying to run portable apps from a UNC path, though that certainly doesn't indicate that it doesn't happen). I certainly haven't heard people clamouring for such functionality as you're suggesting now; if it can be demonstrated that more people would be benefited by the implementation of such a feature, we're more likely to follow it up.
I am a Christian and a developer and moderator here.
“A soft answer turns away wrath, but a harsh word stirs up anger.” – Proverbs 15:1
I do see your point about the folders, though arguably once established, \\server\share\a\b\c won't change from system to system, so--setting aside how I got the folder created initially--it really is closer to your X:\ Y:\ change. X:\a\b\c Y:\a\b\c ?
Speaking as a developer it's handy to keep one set of apps on my server and use them in the various virtual machines that come and go. So yea I'm probably not the average user.
Cheers.
#define VC_EXTRALEAN
#define WIN32_LEAN_AND_MEAN
#include "windows.h"
#include "WinNetWk.h"
#pragma comment(lib, "mpr")
#include
int _tmain(int argc, TCHAR* argv[])
{
TCHAR unc[1024]; // full path to exe.
PTSTR dir; // subfolder info.
bool map = false; // when true, map the unc to drive.
PTSTR drive = NULL; // drive letter and colon
/*
** Get path to EXE. Can be one of:
**
** P:\exe or \\server\share\exe
** P:\sub1\sub2\exe or \\server\share\sub1\sub2\exe
**
** in any case, exe is not interesting so drop it, bt leave trailing \
*/
::GetModuleFileName(NULL, unc, 1024);
dir = _tcsrchr(unc, _T('\\'));
dir[1] = 0;
/*
** Unc's start with \\
** Determine if program was started from UNC
** TODO: may need additional testing for the seldom used \\?\ syntax
*/
if (unc == _tcsstr(unc, _T("\\\\")))
{
/*
** \\server\share\ or \\server\share\sub1\sub2\
** Cut \\server\share\
** \\server\share\sub1\sub2\
** here ---^
** unc will hold \\server\share
** dir will hold nothing or sub1\sub2
*/
dir = _tcschr(unc + 2, _T('\\'));
dir = _tcschr(dir + 1, _T('\\'));
*dir++ = 0;
/*
** TODO: look for an existing drive letter that already connects
** to same UNC. Save drive letter for use below.
*/
/*
** If no mapping found,
** TODO: use 'next available' drive or configuration setting?
*/
map = (NULL == drive);
if (map)
{
drive = _T("P:");
/*
** Create a new mapping to unc using existing credentails.
** (should always work since code is running from there)
*/
NETRESOURCE nr = {0};
DWORD result;
nr.dwType = RESOURCETYPE_DISK;
nr.lpLocalName = drive;
nr.lpRemoteName = unc;
result = WNetAddConnection2(&nr,
NULL,
NULL,
CONNECT_TEMPORARY | CONNECT_CURRENT_MEDIA);
if (NO_ERROR != result)
drive = NULL; // handle below?
}
if (NULL != drive)
{
/*
** A new or existing drive letter was found.
** Assemble new path from those pieces.
**
** TODO: buffers overlap, but should aways be
** shoreter than \\x\y. Test, Test, Test.
*/
_tcscpy_s(unc, 1024, drive);
_tcscat_s(unc, 1024, 0 != *dir ? dir : _T("\\"));
}
}
/*
** At this point, unc contains the folder where the EXE lives
** and it always ends with a \.
** If drive mapping was successful or unnecessary this path will
** start with a drive letter, otherwise it will still be a UNC.
** TODO: abort the launch or blunder ahead
** use this path to find and launch PortableAppsLauncher.exe
*/
return 0;
}
Chris, what are the chances we can enable UNC within PAL and then have a setting for apps that don't work from UNC (Google Chrome) to show the error message instead? I'm updating my custom launchers and the PA.c Installer to support UNC paths. And it seems most apps now work from them alright.
Sometimes, the impossible can become possible, if you're awesome!
The UNC path restriction is very definitely there for PortableApps.com's sake, not for the base app's sake.
From a UNC path, what does %PAL:Drive% mean? It would require yet another reworking of how paths are handled in PAL, and I'm not convinced it can be done correctly (we really do depend on drive switching for a number of things).
It would require some work in PAL and a considerable amount of extra work on all apps, to support what is a corner case. Since supporting mapping to a drive letter in the Platform is an activity which can be implemented more simply, only once and in one place, I think it should be considered a better and more efficient solution (the only detractor from it is that it would require the Platform to be run). Especially as we're more likely to have apps working from a mapped network drive than from a UNC path.
I am a Christian and a developer and moderator here.
“A soft answer turns away wrath, but a harsh word stirs up anger.” – Proverbs 15:1
PAL:Drive should basically just use NSIS' GetRoot function as in the NSIS documentation example:
That way we're just using the existing functions. And this is how Windows thinks of UNC paths in terms of a 'root' as well. And if a user moved from \\NetworkDrive\Portable\PortableApps\AppNamePortable to D:\PortableApps\AppNamePortable, it would be something we could handle.
Additionally, for the most part, users of UNC paths will never be moving apps. They just want to be able to run them from there. And I think it best if we just got out of the way. So, we just have a new setting for apps that can't do UNC. And we need to test out all the apps to see which ones work and which don't.
Sometimes, the impossible can become possible, if you're awesome!
Unless I'm reading the code wrong, it looks like PAL:Drive IS set using GetRoot, so theoretically, already should support UNC paths.