NIPkgMgrTempUnique not actually unique?

[jfolerka]

I'm using NIPM 23.8 to build a collection of packages and a feed to distribute an application, some drivers, and some software utilities.

I noticed that when installing multiple packages some of them don’t install correctly as files seem to be overwritten/added to the installation directory. To troubleshoot this, I added a customExecute step at the beginning of my instructions file for all of the affected packages. The customExecute step calls cmd.exe with arguments='/C echo "%NIPkgMgrTempUnique%">>"%Desktop%\myDbugFile.txt"'.

I could see that all of the packages reported the same subdirectory at “%TEMP%\NIPackageManager\GUID” I expected the “GUID” part of the path to be unique for each package (per the documentation here: https://www.ni.com/docs/en-US/bundle/package-manager/page/installation-target-roots.html)  but in this case they are all the same (I got the same line of text repeated for each package).

The package sources are located in an NIPkgMgrTempUnique subdirectory under the data directory.

[Scott_Richardson]

Thanks for reporting this. Looking at the code implementation it appears that the folder is transaction unique and not package unique, so this is different than documented and we will investigate.

The usefulness of NIPkgMgrTempUnique is for custom executes. If your package is using post install custom executes and wait for them to complete, you should not expect any conflict. If not waiting or you are using post-all install custom executes, you will need to update your package to install the files that the custom executes operates on to a unique subdirectory of NIPkgMgrTempUnique, e.g. the package-name.

[jfolerka · Accepted solution]

Hi there, thanks for replying.

Currently the customExecutes  are configured as post install and they are also configured to wait for completion. However, the files from a previous package are not cleared (or not fully, at least) by the time a new package is unpacked into the NIPkgMgrTempUnique folder so there is some clobbering (or "contamination") going on. I've been able to verify that this is in fact happening: either files from a package that has finished installing are still present and/or if a subsequent package has files that have the same filename as a previous package's files they will get untimely deleted before the package that needs them has used them (likely because of the delete operation of the previous package taking place, or just file system lag).

For now I did use the workaround of creating a uniquely-named subfolder within NIPkgMgrTempUnique to avoid this; everything is working as intended.

[Scott_Richardson]

My understanding is that the current behavior is to delete the files in the temp directory after the transaction, so I would expect that a second package's files would replace the first package's files but after the package had completed installation and the custom execute completed if you were properly waiting.

Can you give more information on the symptoms that you were seeing when the second package did not install properly?

[jfolerka]

Hi there, yes. I believe that is indeed the case. At least the "delete" is started after the transaction but it appears the file system doesn't have enough time to fully carry out the deletion before the next package's files are placed in the same directory.

Let's say you have 3 packages, each with three files in NIPkgMgrTempUnique (I suspect this would also happen in NIPkgMgrTemp):

• Package 1:
  • a.txt ("package 1 a")
  • b.txt ("package 1 b")
  • c.txt ("package 1 c")
• Package 2:
  • d.txt ("package 2 d")
  • e.txt ("package 2 e")
  • f.txt ("package 2 f")
• Package 3:
  • b.txt ("package 3 b")
  • f.txt ("package 3 f")
  • h.txt ("package 3 h")

You place a customExecute to print out the output of dir using cmd.exe to a text file in each package. Try to install all packages at once and you might get:

• Package 1
  • a.txt ("package 1 a")
  • b.txt ("package 1 b")
  • c.txt ("package 1 c")
• Package 2
  • a.txt ("package 1 a") (if the file system hasn't finished deleting)
  • b.txt ("package 1 b") (if the file system hasn't finished deleting)
  • c.txt ("package 1 c") (if the file system hasn't finished deleting)
  • d.txt ("package 2 d")
  • e.txt ("package 2 e")
  • f.txt ("package 2 f")
• Package 3
  • a.txt ("package 1 a") (if the file system hasn't finished deleting)
  • b.txt ("package 3 b") (overwritten if the file system hasn't finished deleting, might be OK)
  • c.txt ("package 1 c") (if the file system hasn't finished deleting)
  • d.txt ("package 2 d") (if the file system hasn't finished deleting)
  • e.txt ("package 2 e") (if the file system hasn't finished deleting)
  • f.txt ("package 3 f") (overwritten if the file system hasn't finished deleting, might be OK)
  • h.txt ("package 3 h")

This is not 100% repeatable because it seems to depend on how far the file system is in carrying out the file deletion process so every time you run it you might get different results.