Bug with profile folder in standalone version

  • I installed x64 version standalone (portable option) on disk D: Vivaldi started. I closed it. After i moved browser folder to other disk. Start Vivaldi and it creates profile folder on last place - d:\vivaldi\profile Does Vivaldi use regedit settings of path? I checked standalone! It shouldn't use regedit or something. All settings should be in program folder.

  • I also use Vivaldi in stand-alone mode. In the stand-alone installation's \application sub-folder, the file stp.viv carries the path to where the main Vivaldi program folder was placed at installation. There may be other Vivaldi files with similar paths or perhaps a registry key or two… I haven't searched exhaustively. Consequently, the "portability" aspect of a stand-alone Vivaldi install is questionable. Hence simply moving the installation between drives can create problems unless the new drive letter and its folder structure mimics the installation path originally used.

  • Vivaldi Translator

    I have 2 separate "standalones" the previous 64bit and the new 32.
    Both open the same session, so the registry is being written to.
    Not so clever if visiting someone else's PC, as you will either open their session, or leave yours behind for them to discover.

    Oppsy !
    We can assume this security flaw will be removed by the next update.

  • Same problem here. Standalone should be movable, nothing outside the installation folder. Opera can be moved without problem, so should Vivaldi.

  • I agree, the standalone installation needs to be a true standalone.

    In the mean time, I spent some time trying to see if a standalone installation can be successfully relocated, but don't yet have all the answers (see Tl;dr at end for results summary):


    I also use Vivaldi in stand-alone mode. In the stand-alone installation's \application sub-folder, the file stp.viv carries the path to where the main Vivaldi program folder was placed at installation. There may be other Vivaldi files with similar paths or perhaps a registry key or two… I haven't searched exhaustively.

    In my v1.0.135.2 standalone installation, the following files are the only ones containing a plain text instance of the installation path (one occurence each):
    \Vivaldi.\Profile\Default\Extension Rules\LOG
    \Vivaldi.\Profile\Default\Extension State\LOG
    \Vivaldi.\Profile\Default\Local App Settings\mpognobbkildjkofajifpdfhcoklimli\LOG
    \Vivaldi.\Profile\Default\Local App Settings\mpognobbkildjkofajifpdfhcoklimli\LOG.old
    \Vivaldi.\Profile\Default\Session Storage\LOG
    \Vivaldi.\Profile\Default\Session Storage\LOG.old

    I wouldn't think any of the LOG files would matter, but I could be wrong.

    As an experiment I made a complete copy of my v1.0.135.2 standalone installation on a USB memory stick and temporarily renamed the original v1.0.135.2 standalone folder on my HDD. Then I tried just changing the installation path in the stp.viv file to the new location on the memory stick and ran Vivaldi from the memory stick. It not only recreated the Profile folder on my HDD, but it opened only one tab, the Vivaldi.net page, like a new installation does (i.e., using none of the copied Profile, including Session/Tabs, on the memory stick): FAIL !!! :pinch:

    So I figure there must be some registry involvement and wondered if there might be a simple regedit that might "fix" the problem. NirSoft's RegScanner found several registry keys containing my original v1.0.135.2 standalone installation path (on 32-bit Windows), all of which were last modified at time of my v1.0.135.2 installation or since. There were no keys that referred to my previous (still-installed) v1.0.129.2 standalone installation, so I assume those were all the same keys and overwritten by v1.0.135.2). Listed alphabetically, the keys containing the installation path are:

    HKCU\Software\Microsoft\IntelliPoint\AppSpecific\vivaldi.exe | Path
    HKCU\Software\Microsoft\IntelliType Pro\AppSpecific\vivaldi.exe | Path
    HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\ComDlg32\FirstFolder | 2
    HKCU\Software\Vivaldi | DestinationFolder
    HKCU\Software\Vivaldi | InstallerSuccessLaunchCmdLine
    HKCU\Software\Vivaldi\Commands\on-os-upgrade | CommandLine
    HKLM\SOFTWARE\Clients\StartMenuInternet\Vivaldi.PZHLKFFZIODLSCBKOIPJKRIZOI\Capabilities | ApplicationIcon
    HKLM\SOFTWARE\Clients\StartMenuInternet\Vivaldi.PZHLKFFZIODLSCBKOIPJKRIZOI\InstallInfo | ReinstallCommand
    HKLM\SOFTWARE\Clients\StartMenuInternet\Vivaldi.PZHLKFFZIODLSCBKOIPJKRIZOI\InstallInfo | HideIconsCommand
    HKLM\SOFTWARE\Clients\StartMenuInternet\Vivaldi.PZHLKFFZIODLSCBKOIPJKRIZOI\InstallInfo | ShowIconsCommand
    HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\vivaldi.exe
    HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\vivaldi.exe | Path
    HKLM\SYSTEM\ControlSet001\services\SharedAccess\Parameters\FirewallPolicy\FirewallRules | {2B817DA5-9BA1-4987-915F-C0EEDA39AB06}
    HKLM\SYSTEM\CurrentControlSet\services\SharedAccess\Parameters\FirewallPolicy\FirewallRules | {2B817DA5-9BA1-4987-915F-C0EEDA39AB06}

    I haven't checked whether the PZHLKFFZIODLSCBKOIPJKRIZOI and {2B817DA5-9BA1-4987-915F-C0EEDA39AB06} are common across machines for Vivaldi or unique to my machine, but I suspect the latter.

    Of those keys, I suspect HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\vivaldi.exe might be most relevant (if any) to the "portability" problem, but I don't have time to check right now whether changing it alone to the new path would "fix" the problem.

    Interestingly, 2 keys I thought were probably only used by the Vivaldi installer and not relevant to the browser executable or profile (DestinationFolder and InstallerSuccessLaunchCmdLine) were the only keys with a "modified" time changed by my experiment with the USB memory stick. However, the key content was unchanged and still pointed to my original standalone installation path on the HDD. I already deleted the debug.log (or error.log?) in the copied Application folder, but it had an error with RelaunchChromeBrowserWithNewCommandLineIfNeeded. That "NewCommandLine" may be internally coded to point to the path designated in the DestinationFolder or InstallerSuccessLaunchCmdLine keys, recreating the Profile folder in the original location, so perhaps the path would need to be changed in those keys as well.

    Finally, if one manually made the necessary changes in other keys, I don't know if Windows would automatically update the path in \FirewallPolicy\FirewallRules when you run Vivaldi, or if that would have to be manually edited as well.

    …But ultimately, I hope the standalone installation will be reworked to make it a truly portable standalone.

    Tl;dr: Just changing the standalone installation path in the \Vivaldi\Application\stp.viv file is not enough to successfully relocate a standalone installation; some (at this point unknown) registry changes appear to be necessary as well.

    (probably more than anyone wants to read, but after writing it up, gotta post it :P …if nothing else so I can refer back to it myself)

  • @Dr.Flay:

    I have 2 separate "standalones" the previous 64bit and the new 32.
    Both open the same session, so the registry is being written to.

    I can't replicate this using 2 separate 32-bit standalone installations on 32-bit Win7 (i.e., the 2 installations maintain and re-open separate sessions), but I haven't yet installed either 32-bit or 64-bit Vivaldi my 64-bit Win7 machine. (I plan to install both.)

    As far as I can tell, all the session info used when Vivaldi re-opens is stored in Profile\Default\Current Session and Profile\Default\Current Tabs, with backups of the previous session (apparently) in Profile\Default\Last Session and Profile\Default\Last Tabs, similar to Olde Opera's autosave.win and autosave.win.bak. Also, as far as I can tell, there is nothing in the registry pertaining to standalone sessions (see registry search results in my previous post).

    I don't know if it's even possible, but are your 32-bit and 64-bit executables by any chance somehow installed in the same installation destination folder (e.g., Vivaldi\Application) so they also share the same profile (e.g., Vivaldi\Profile)? (Not sure that's even possible, but it's the only way I can imagine them opening the same session… ...and then I would think only one could be open at a time or they would conflict and probably crash.)

    When I do try it on the 64-bit Win7 machine, I will also use different names for the 2 installation folders (e.g., Vivaldi32 and Vivaldi64) to ensure they stay separate, and I'll post back if I learn anything else that might be useful.

  • Although it appears newscpq "abandoned the idea to force a portable version" in this post in another thread, it appears to me that maybe the chromium –user-data-dir command line switch described there (possibly in combination with a symbolically linked "user data" folder ???) might be able to overcome this current portability limitation with standalone Vivaldi installations.

    But exactly how to do this is probably a little over my head. Is anyone else who understands it a little better interested in trying to sort it out?

  • Why don't you try to change the content of the "stp.viv" file to "." (without quote marks)? Or even to ".."? ;)

  • @tardigrada:

    Why don't you try to change the content of the "stp.viv" file to "." (without quote marks)? Or even to ".."? ;)

    My experiments so far (with substituting a new path for the old path) indicate changing the path in the stp.viv file alone is not sufficient (see 3rd post above yours).

    But if you try it and it works, let us know. That would be delightful!

  • Tried. It works.

  • @tardigrada:

    Tried. It works.

    OK, thanks! I'll try again as soon as I get a chance (might be a few days).

    I'm not a programmer, and not familiar with the implications of what appears (to me) to be a "null" path (for lack of a better, more accurate term). Can you explain why that simple path change in stp.viv might work, when substituting an explicit new path doesn't? (Is it functioning as sort of a "wild card" path or something like that?)

  • The obvious differences between Vivaldi's "standalon installation" and what is widely recognized as "portable" have already been discussed in several threads. (Search for "portable" or "portable Vivaldi".) Thus the portability problem doesn't seem to be a bug. "Standalone" in the case of Vivaldi only means that the profile folder is placed within the program folder instead of the user app folder. It doesn't mean portability (i.e. self containing program folder, no traces / trace cleaning up after usage). It seems a bit strange for me, but that is my personal opinion only.

    What you refer to as "null path" is a so called "relative path". "." means "the same folder relative to current position" and ".." "one folder instance above the current position". The content of the "stp.viv" is the absolute path of the installation (describing the location from the root on). Whatever that path is, Vivaldi seeks for the Profile folder according to that information and recreates it when you move the program folder. Fortunately when you change it to a simple relative path, the program launcher seeks for the Profile folder at a location relative to its current position.

    The effects of "." and ".." are slightly different. "." preserves the default folder structure (Vivaldi folder with the Profile and Application folders as subfolders). ".." places the Profile folder into the Application folder (it is than more like the folder structure of a portable installation of Opera). I prefer this folder structure and have used Vivaldi that way since its very first public version.

    The registry entries seem to be still there (when I start a Vivaldi installer it "remembers" the location of the last installation), but the program folder can be moved around the computer and Vivaldi won't recreate the Profile folder at the location of the first installation.

    I haven't tried to copy Vivaldi to a USB stick and I don't have a standard installation of it either therefore I don't know whether it works from a USB stick (I guess it does) or if there are any conflicts between a a standard installation and a portable one (could be the case due to the registry entries).

    BTW, I ain't a programmer either, thus my technical explanations may be incorrect. For the same reason I can't answer the question why the substitution of the original content of the "stp.viv" file by a different absolute path did not work.

  • Thanks very much! I look forward to trying it.

    Yes, I already understood the basic distinction between standalone and portable (that is, when not used synonymously, as they often are).

    But I was looking for exactly the result that the your 2 relative path options apparently provide. However, I was going at it by trying to "force" a new profile folder path by explicitly specifying the new path in stp.viv.

    In reality it seems that an explicitly specified new path is effectively ignored, while the 2 relative path options effectively ignore the original standalone installation folder path. …Not the first time I've discovered that what initially makes sense (to me) is not the case, and is sometimes opposite of what I would expect. :P

    I will probably try it on a USB memory stick so I can also find out if perhaps it is truly portable. (Unfortunately, a nearly unused but 2-year-old 128GB stick somehow failed with my first attempt to test portability using my approach. Windows now sees it as an empty removable drive--e.g., a CD/DVD drive--rather than a writable USB memory stick. :pinch: )

    Thanks again! :)

  • You're welcome, my pleasure. Please let me know how it worked.

  • I clarify here, that what I abandoned was my intention to break into pieces the portable installation. I was trying to separate the user data directory away from its' default location, but then I stopped my nonsense (why was I trying to break something designed to stay unite?) and decided to just use the command line switch –used-data-dir, on a standard installation.

    That perfectly worked: Vivaldi was installed in C: and the user profile folder was where I wanted it.

    I am not using a portable version anymore, I can't help here.


  • @newscpq:

    I was interested in your perspective here. Thanks for checking in to clarify. :)

    (BTW, when I quoted you above I had noticed that you said "I abandoned the idea to force a portable version to be broken into pieces…", but at the time I wasn't sure of the significance of broken into pieces, so I just conveniently left it out. :P)

  • Here some additional information for those who are interested in "portability".

    I tried Vivaldi's updater on standalone installations with modified "stp.viv" files.

    The updater works fine with the "." modification (i.e. unaltered folder structure).

    The ".." modification (Profile folder in the same folder where the "vivaldi.exe" is) let the updater make a standard installation (with the profile folder in the AppData folder) instead of simply updating the standalone installation.

  • Nice update! Thanks! ;)

  • @tardigrada:

    The effects of "." and ".." are slightly different. "." preserves the default folder structure (Vivaldi folder with the Profile and Application folders as subfolders). ".." places the Profile folder into the Application folder (it is than more like the folder structure of a portable installation of Opera).

    Hi, tardigrada,

    I just now finally got around to trying this (by just extracting Vivaldi to a new standalone folder from the vivaldi.7z file contained in teh installer), and thought I'd post back to mention (and clarify for other users) that my results were the opposite of your description:

    stp.viv with *.* placed in the standalone installation folder creates a Profile folder inside the version numbered Application folder

    stp.viv with *..* placed in the standalone installation folder preserves the standard Vivaldi standalone folder structure with a Profile folder and a (version numbered) Application folder at the same level in the standalone installation folder

    (I imagine you just accidentally reversed them, and I added the bold colored fonts to make the pairing of relative path with result as clear as possible, because I almost got them backwards again myself while posting this :P)

    FWIW, I also noticed when I used *.* inside stp.viv the Dictionaries folder was not created in the usual place in the standalone folder nor in the numbered Application folder, nor in the Profile sub-folder, but when I used *..*, the Dictionaries folder was created in the standard standalone folder structure at the same level as the Profile and numbered Application folders.

  • Hi, gdveggie,

    I can confirm your findings. Your description is correct, I could reproduce your test (unpacking, creation of the "stp.viv" file with the two different contents) and its results.

    And now, here comes the mysterious part: My description was correct too, at least it correctly described my experiences. I don't know why it worked the exact opposite way. I started at the very beginning with a standalone installation, modified the "stp.viv" (so that I could relocate it) and made regular updates by placing the new files in my Vivaldi program directory. This must have been the reason for the observed behavior, probably involving the registry entries. Pity I haven't had the opportunity to try copying the program to a USB drive and see what happens when launched from there on another computer completely untouched by Vivaldi.

    FYI, I have recently found the following two modifications of the "stp.viv" on a site dealing with portable softwares:

    1. ".." preserving the original standalone folder structure.
    2. "..." placing the "Profile" folder (or the "User Data" as it is called in the latest snapshot) in the same folder where the launcher and the numbered version folder is.

Log in to reply

Looks like your connection to Vivaldi Forum was lost, please wait while we try to reconnect.