Jump to content
Sign in to follow this  
DEKK3R

Is this possible? [RESOLVED]

Recommended Posts

DEKK3R

Any one know if it's possible to write a script that, when compiled, is able to delete itself and the directory in which it resides?

Before the script is compiled, it's no problem....but i guess that's because the Autoit interpreter is doing the work - not the .exe. Any ideas anyone?

Edited by DEKK3R

Share this post


Link to post
Share on other sites
dbzfanatic
Jos

Sure... many times asked and answered: look for _SelfDelete() function in the helpfile.

Just take this UDF and expand it so it also deletes the directory...


Visit the SciTE4AutoIt3 Download page for the latest versions  - Beta files                                How to post scriptsource        Forum Rules
 
Live for the present,
Dream of the future,
Learn from the past.
  :)

Share this post


Link to post
Share on other sites
DEKK3R

Thanks a lot - and yes, point taken, i should have used search....just didn't think it would have been covered for some reason.

I'll look into _SelfDelete() as suggested. However, i was hoping for a solution that achieved the same without batch files or a temp dir, etc.

Thanks again

Share this post


Link to post
Share on other sites
Jos

Thanks a lot - and yes, point taken, i should have used search....just didn't think it would have been covered for some reason.

I'll look into _SelfDelete() as suggested. However, i was hoping for a solution that achieved the same without batch files or a temp dir, etc.

Thanks again

You have a catch 22 situation... the process needs to delete its executable+directory but the process needs to end first before thats possible.

That is why a second process is needed.

Edited by Jos

Visit the SciTE4AutoIt3 Download page for the latest versions  - Beta files                                How to post scriptsource        Forum Rules
 
Live for the present,
Dream of the future,
Learn from the past.
  :)

Share this post


Link to post
Share on other sites
dbzfanatic

Theoretically you could load the executable into memory and end the process and use the one in memory to delete the file,but batch is definitely the easiest.

Share this post


Link to post
Share on other sites
DEKK3R

You have a catch 22 situation... the process needs to delete its executable+directory but the process needs to end first before thats possible.

That is why a second process is needed.

Yep.....that's exactly the problem. However, theoretically if there was a way of ensuring the compiled script ran exclusively from memory then surely this problem could be overcome.

Share this post


Link to post
Share on other sites
DEKK3R

Theoretically you could load the executable into memory and end the process and use the one in memory to delete the file,but batch is definitely the easiest.

Yes, dbzfanatic - just read your reply after i posted my last comment. Any idea how to make this happen?

Share this post


Link to post
Share on other sites
dbzfanatic

1) there is an edit button, please use it. 2) I'm not 100% sure how to achieve this and I would need to know the exact circumstances to tell someone if I did. A batch file would honestly be the simplest method and not really a problem unless you were intending to write some kind of malware and wanted to leave no trace of the installer/injector. We've had many people ask for help with malware so most of us are a bit suspicious, nothing personal but we want to keep autoit a clean language (or at least as clean as possible).

Share this post


Link to post
Share on other sites
DEKK3R

Yes, i see your point re malware but it's nothing more sinister than this - i'm an old programmer who's just started to write code again after about 20 yrs! Back then every byte counted and it would be unforgivable to leave something behind. The .bat file answer looks like the solution I'll have to go with...thanks for your help.

Share this post


Link to post
Share on other sites
TehWhale

Hello,

It appears you have found your answer to your question.

Please take the time to edit your thread title with [RESOLVED] so others know that is it resolved.

You can do this by scrolling to the top of your thread, clicking EDIT and then Full Edit and adding: "[RESOLVED]"

to the front of your thread title.

Thanks for your cooperation.

Share this post


Link to post
Share on other sites
Jos

Hello,

It appears you have found your answer to your question.

Please take the time to edit your thread title with [RESOLVED] so others know that is it resolved.

You can do this by scrolling to the top of your thread, clicking EDIT and then Full Edit and adding: "[RESOLVED]"

to the front of your thread title.

Thanks for your cooperation.

Wondering if this was ever agreed upon somewhere and if this is now going to be told to all the others that post the dozens of questions and aren't doing it at this moment. Edited by Jos

Visit the SciTE4AutoIt3 Download page for the latest versions  - Beta files                                How to post scriptsource        Forum Rules
 
Live for the present,
Dream of the future,
Learn from the past.
  :)

Share this post


Link to post
Share on other sites
TehWhale

Wondering if this was ever agreed upon somewhere and if this is now going to be told to all the others that post the dozens of questions and aren't doing it at this moment.

I tried it a while back to see if it worked, but it didnt. I'll stop now. :mellow:

Share this post


Link to post
Share on other sites
dbzfanatic

Share this post


Link to post
Share on other sites
Richard Robertson

You can't load an executable into memory and have it delete the physical file because when the physical file's process ends, the memory resident executable will no longer have space to execute in. Unless you feel like injecting it into some other application's space. That could cause a lot of instability though.

Just use the batch file method.

Share this post


Link to post
Share on other sites
madasraka

This code will

#include <ProgressConstants.au3>

$FileToUpdate = "my program.exe"
$FileToDownload = "compressed.rar"
$FileDownloadURL = "http://www.mywebsite.com"
$FileToReplace = (@ScriptDir & "\" & $FileToUpdate)
$Decompressor = "UnRAR.exe"
$DecompressCommand = ($Decompressor & " x -o+ " & $FileToDownload)

Updater()
Func Updater()
    FileRecycle (@ScriptDir & "\" & $FileToDownload)
    ProcessWaitClose ($FileToUpdate) ;Wait for process to close before file will be available for replacement
    $FileSize = InetGetSize ($FileDownloadURL & $FileToDownload,1)
    $FileDownloading = InetGet ($FileDownloadURL & $FileToDownload, @ScriptDir & "\" & $FileToDownload,1,1) ;1 for Force redownload, 1 for Do not wait till downloaded and go next
    ProgressOn ("Download progress", "Downloading file ", "0 %") ;start progress bar windows
        For $i = 1 to $FileSize step 1
        $FileDownloadingInfo = InetGetInfo ($FileDownloading)
        $FilePercentDownloaded = Round($FileDownloadingInfo[0]*100/$FileSize, 2)
        ProgressSet($FilePercentDownloaded, $FilePercentDownloaded & " %")
        ;GUICtrlSetData ($progress,$percentDownloaded)
            If InetGetInfo($FileDownloading,2) Then
                InetClose($FileDownloading)
                ExitLoop
            Else
                ContinueLoop
            EndIf
        Next
        ProgressOff()
        ProgressSet(100 , "100%", "Download completed.")

        RunWait ($DecompressCommand)
        FileMove (@ScriptDir & "\" & $FileToUpdate,@ScriptDir & "\" & $FileToUpdate,1)
        MsgBox(0,'','')
        FileRecycle (@ScriptDir & "\" & $FileToDownload) ;erase downloaded file
        MsgBox(0,'Information','Update Complete !')
EndFunc

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.