In SL 1.12 a serious bug was introduced in this function, causing the bytecode to be stripped from the source code and loaded as a seperate, unnamed inventory object that would be named "Old Script". Any scripts that used llRemoteLoadScriptPin() between the deployment of 1.12 on 8/23/2006 to the rolling restart on Friday 8/25/2006 created these... problems. llGetScriptName() is unable to differentiate between the different scripts as they're ALL named "Old Script", and any inventory functions will only work on the first instance in inventory. Future update scripts will need to be written to look for these "Old Scripts" and their uncompiled properly named source stubs and handle them accordingly. -DragonEccleston

If the owner of the object containing this script can modify the object identified by the key target, and if the pin matches the PIN previously set using llSetRemoteScriptAccessPin (on the target prim), then the script name will be copied into target.

If the target prim already contains a script with the same name as name, it will be replaced without any warning.

Notes:
* target must be a different prim than the one containing this script. llRemoteLoadScriptPin cannot copy a script into itself. Also, target must identify a rezzed prim, existing in the world. It cannot be in the inventory of an object.
* It might not have gotten clear from the above statement: The owner of the prim containing THIS statement must have modify rights on the OTHER object. Also see the remark below about handing out a helper prim.

If you need to update scripts for your end users, consider putting the updated scripts inside of an object which is then delivered directly to end users via llGiveInventory. This object, if rezzed in the same sim as the item being updated, can then negotiate a PIN with the object and the scripts can be updated/enabled automatically.
-- DirtyMcLean