I'm trying to have the installer [NSIS] deleted after my electron app is installed on a device, so that the user needn't do so
Is there a possible way to achieve this
So I would not really recommend it but you could try to use the Delete function, specify your installer-file and set the /REBOOTOK Flag.
The code would look something like this:
Delete path\myInstaller.exe /REBOOTOK
This Flag tries to Delete the File right away and if it fails, wich it will since the installer is running, it will delete it after a reboot.
Just keep in mind that you would have to reboot your computer after the installation or the file will not be deleted.
Let me know if this solved your problem.
Related
So, I've been looking for solution's on the web but I can't find any. Every time I try to add something to path it deletes it right after I close it. This is on my user. However if you do it as administrator it will save it. I can't use here because the admin is another profile and I all the developing tools are in my profile. Can any of you help me.
I'm developing an App using the latest version of Electron-builder (using AutoUpadate).
Is there any way to know that the App is running for the first time after installation?
Ps: I have tried using electron-config but the user data files are not deleted after uninstall, and I needed to do some things with every installation (even if it's on the same machine).
Check for the squirrel-firstrun flag:
var cmd = process.argv[1];
if (cmd == '--squirrel-firstrun') {
// Running for the first time.
}
(you don't need to install anything for this to work)
Ref.
Your app could, in case that it doesn't exist, write a folder/file (with filename based on a timestamp?).
When app starts, always look for the file.
If there is no file, means its first time, do what you want and write file.
If there is a file means it's not the first time.
Don't know if there is something at Electron API!
I'd been working on a plugin when I discovered this. I can't say for sure if this behavior happened before or not on my machine (it doesn't on our test server, a Linux box), but after attaching a file, I can't delete it until the server restarts. I can't delete through the UI or by manually navigating to the server directory and trying to delete from there.
Has anyone ever encountered this before? Could it be something environmental on my box??
Most probably it's a permission issue in that folder, which allows your JIRA user (a user under which privileges JIRA instance runs) to create files, but not to delete them (or something even more fun) :) Try deleting the temp folder (where your uploaded attachments reside) and recreate it again, adding your JIRA web user to the access list for that folder.
The workaround to delete files, when some other process is holding a lock on the file, without having to terminate that process, is to use Unlocker. But be warned, when Unlocker unlocks a file it does that in a way which does not notify the lock holder that the file has been unlocked by force. That means that the lock holder still thinks it holds the lock on the open file which it doesn't (the file handle is invalid). That means that some applications might crash due to unexpected state of the supposedly open file. Btw, I've been using Unlocker since forever and it rarely caused any crashes, but it's better to be warned.
just tried to create a snapshot of one of my projects. It didn't work, and Xcode did throw the following error at me: "Unable to create a snapshot. fatal: You don't exist. Go away!"
Source control commit doesn't work either. Ok, obviously there's something wrong with my local repository. I don't have the slightest idea, what that could possibly be, though. I have not committed in quite a while, but except some updates to Xcode itself, nothing major happened to the project folder, as far as I can remember.
So, what can I do about it? Is it possible to deactivate source control for that project and then start over again with source control with the projects current status? I don't need the previous versions anymore, so that doesn't need to be taken care of.
Thank you!
Looking into the git source code, this error message is generated only if
pw = getpwuid(getuid());
fails.
It indicates that the system wasn't able to find an entry for your user account in /etc/passwd or equivalent.
This can happen if your account is removed (via deluser, userdel, or something else) while you're logged in, or if you don't have read permissions on /etc/passwd (the latter should never happen).
Try the following commands at a terminal prompt:
whoami
id
ls -l /etc/passwd
grep "^${USER}:" /etc/passwd
According to the git documentation, this is the meaning of your particular error:
You don't exist. Go away!
The passwd(5) gecos field couldn't be read
This typically means the system doesn't know who you are (you'll see this sort of error on a Linux system if you delete someone's user account while they're still logged in). Is everything else working? That is, can you log out and log back in without a problem? Do other terminal commands operate correctly? What about the id command?
Can you interact with your repository on the command line? What happens if you cd into the directory and try something like git status?
WendiKidd's solution of just starting from scratch is probably the simplest thing to do, assuming it works, but you'll lose any change history already associated with your project.
I had this issue with git and running
dscacheutil -flushcache
in the terminal fixed it.
I would suggest creating a new project entirely, copying your code etc. files out of the old project, and simply migrating over into a new one (which you could then recommit to another source control directory). That seems like the easiest solution; this is a very odd error, and I've come across things in the past that are either unfixable or would take more effort to fix than taking 10-15 minutes to just set up a new project.
So that's what I'd recommend--hopefully that will fix your problem, and whatever xcode is mad at is in some hidden file or the .xcodeproj itself, and not in the files you'd need to migrate over.
Is there any way to delete a file when its using by any program or other process in windows?
I searched and found this 2 ways:
1- using RunOnce key in Registry;
I'm not gonna use this because i dont want to wait for windows restart or anything else... prefer to do it ontime!
2- using the way declared in this page: http://www.delphipages.com/forum/showthread.php?t=201190
the problem here is its useful under NT windows, i need a way works on all Windowses!
Thank you.
the problem here is its useful under NT windows, i need a way works on all Windowses!
All modern desktop Windowses (XP, Vista, 7) are also NT. Do you really need to work with NT<4 or Win98? Or even Win CE/Mobile/Phone? Probably not.
If you need to delete an open file straight away, about the only thing you can do is attach to each process using debugger privileges, see if it has any handles open on the file, and if so close them underneath it. You can do this the manual way using eg Process Explorer. Many applications won't react well to having their files closed on them; expect them to exception out when they try to do something with the dead handle.
Unfortunately there is no option in Windows to have Unix-style files that can exist attached to a file handle independently of being stored under a filename on disc.
You cant delete a file when someone is using it. No matter how hard you try, windows will not let you. It can work with some files, but in general it does not work.
What you can try is postpone the deletion, when no one is using the file. You can:
1 - use RunOnce, but you dont want that.
2 - Wait in a loop, trying to delete the file. Pseudo code:
DeleteFile
Check if you was able to delete or if file still exists.
if you are able to delete, then exit loop.
That is the best you can do, and what i could remeber.
Try MoveFileEx with MOVEFILE_DELAY_UNTIL_REBOOT flag. Will postpone move or delete action until reboot.
Edit:
If you don't whant to restart the only option is to close those handles. ProcessExplorer does that and works all the time and I have not seen any process to crash. See more info about enumeration handles in a process at
http://www.codeguru.com/forum/archive/index.php/t-176997.html. But keep in mint that you should enumerate all processes in the system and behave different on Vista+ (you need to be elevated)
Your files are most likely locked because some process has a handle open to them. That is the most common reason for the Access denied result when deleting or moving a file.
A really blunt way is to close that handle.
Then Handles tool from SysInternals (you can download the sources too) can do that for you: I have been successfully using that.
Note 1: You need administrative privileges to use it.
Note 2: Closing a handle from another process is considered very rude, and can make that process unstable.