nm35 and rmccue have released Instant FileZilla, the first in a coming line of Instant programs. This program is one EXE file that extracts FileZilla to the temp directory and then runs it. It then deletes the files upon closure of the program.
-Justin
Visit the Community page
Join our forums
Subscribe to our email newsletter
Subscribe with RSS
Follow us on Facebook
Follow us on LinkedIn
Follow us on Twitter
Follow us on Mastodon
Follow us on BlueSky
Please remember that all self-promoted apps must be open source and licensed under an OSI-approved license (GPL, BSD, MPL, etc). If this was simply left off of the product page, please add it in. If this packaging is not open source or not under an OSI-approved license, please delete your post.
Sometimes, the impossible can become possible, if you're awesome!
The license is GPL. The source is available here:
http://www.portasoft.org/e107/download.php?view.15
-Justin
That's cool. I would suggest updating the product page to state that more clearly so people can easily find the license and source. People will probably be more likely to try it with that information on the page, too.
Sometimes, the impossible can become possible, if you're awesome!
Here it goes.....
-Justin
nm35 came up with the concept and version 0.5 and I just added stuff like deleting the files, etc.
----
R McCue
"If you're not part of the solution, you're part of the precipitate."
Awesome job. I like this idea for portable apps. One suggestion/question: would it be possible to automatically maintain the program settings between executions?
I just released version 0.3, which does this. It also adds a system tray icon (a bit buggy, currently only for notifications).
Just drop filezilla.xml in the directory where Instant FileZilla.exe is; every run of Instant FileZilla will copy your settings file there.
~nm35
» PortaSoft -- Portable Application Development
» Personal Space -- Blog, Projects, Etc...
When working on Portable Firefox, we actually considered a similar approach for both Firefox and for some future apps. (U3 was actually doing a similar technique of uncompressing the app to the local drives originally as well) We actually decided not to persue this path for a few different reasons.
Host Impact (When Running) - A given amount of space is required on the local hard drive. This can be checked for by just checking the free space on the volume where %TEMP% resides and ensuring you have enough space for your app plus some padding so the drive doesn't fill.
Host Impact (Crash) - If the app crashes, all of the files you place there are left behind on the local PC. A possible workaround is to create a RunOnce procedure that will clean it up in this event, if you can access that area of the registry, that is.
Security (Normal Use) - If you are copying configuration files (as you are in the case of Instant FileZilla), those files are stored on the local hard drive in the TEMP directory. On shutdown, you are deleting the files, but they can still be undeleted with relative ease, exposing your saved passwords to others. A possible workaround is to include a secure delete functionality within the package.
Security (Crash) - If a crash occurs, your configuration files with your private data is left behind on the local PC, exposing your logins and passwords to others. A possible workaround is to use a RAM disk (though that would probably require admin privs) or to use the RunOnce procedure I mentioned under Host Impact.
The issues above are the main reason we abandoned the approach. The security issues were the kicker. It is still a viable approach for live apps that don't use secure data within them... or that can be redirected to a config file on the host media as opposed to the local machine. But I wouldn't recommend using this with something like FileZilla and saved passwords.
Sometimes, the impossible can become possible, if you're awesome!
I hadn't thought about that. However, we could make an emergency batch file available for download on our site that you could run to erase your tracks. Or even a whole other program that will securely delete your tracks in case of an emergency. I am opposed to including it with the package though, as I would like to keep it one EXE.
-Justin
The secure delete would have to be included by default... but could be inside your single EXE. As for the cleanup, it could originate from the EXE as well.
Sometimes, the impossible can become possible, if you're awesome!
The problem there is that if the "single EXE" crashes before the portable app quits (this possibility is half the reason we even have this issue in the first place), it can't do a secure delete. If the portable app crashes, we don't have the issue... the "self-extractor" which is in the background can still do clean-up.
I suppose it might be better to have a separate download of a batch file that runs a secure delete program to delete the files left behind. nm35?
-Justin
doesn't Spybot S+D include Secure Shredder which does that?
----
R McCue
"If you're not part of the solution, you're part of the precipitate."
If FileZilla itself crashes, it would still clean up. If the app wrapper crashes, all files would be left behind (and the user may not know their files are left behind). If the OS crashes, all files would be left behind (and the user may not know).
Sometimes, the impossible can become possible, if you're awesome!
This is exactly the point I was trying to make. Windows 95/98/Me (the latter two are still more common than you might think) are prone to complete system meltdowns, so even if the wrapper/launcher/whatever-you-wanna-call-it is perfectly stable, the security issue can't be fully addressed, as an OS crash can never be ruled out. Hence, I'd stay away from this as an "official" way of doing things. I don't need my portable applications to be single EXEs... I'm perfectly fine with having a standard list of files. The only advantage I can see to the single EXE solution is compression (it's essentially a self-extracting archive), and if you want that, UPXing all the app's executables is probably a better way to go anyway.
All the executables are UPX compressed anyway. We tryed it.
----
R McCue
"If you're not part of the solution, you're part of the precipitate."
Portable FileZilla is already UPX compressed and debug files removed, hence the small size (3.3MB vs 11.6MB).
Sometimes, the impossible can become possible, if you're awesome!
More people are using multi-user switching and the combinations of logging off and rebooting create chaos for applications that are borrowing either the registry or temp directory. In addition, more security programs are picking up on the run once and blocking reg entries.
The less a PortableApp uses the registry or either Documents and Settings/temp the better. The precedent of writing and then deleting registry settings creates the potential that someone will write some code that will create a “big whoops” for the host when an important key is accidentally deleted.
While the people on this thread are savvy, more and more people are coming to this board who “trust” that the builds are safe and that they have been through QA and even if they are designated “Beta”, are ready to run. Bugs are one thing. Security is another.
John raises a really good issue. What are the parameters for a “responsible and secure PortableApp?” At what point is a release announced?
______________________________________________________
Ridgewood Foundation Open Source Project
Site: ZedFiles Blog: My 19" Universe
The original reason I created this was to learn a bit more NSIS, and to let me have a quick FTP session. There was no reason to keep settings between runs, and I'm probably going to remove that. The only reason for this is so I can just run a single executable instead of downloading a ZIP file and messing with it.
~nm35
What's to mess with? Download the zipfile, extract it somewhere, and the portable app is ready to go. Once all the files are extracted, the only executable you ever have to worry about is (in your case) PortableFileZilla.exe. You can ignore the rest of the app's directory structure if you don't want to be bothered with it. With an official Portable App, you extract a zipfile once and use the app from there. With this "Instant" solution, the archive has to be extracted every time you want to run the program. I don't know about FileZilla, but I know Firefox et al take quite a few seconds to extract (anywhere from 5 to 10 seconds depending on the machine), even when extracted to the local hard drive. You'd repeat that wait every time you want to run the program? I know I wouldn't. Some of the apps take long enough to start up as it is (good example of this: OpenOffice.org). I don't want to double that wait.
Maybe it's just me, but spending time to make an "instant" single EXE launcher is more trouble than it's worth. Besides, a lot of free hosts won't let you upload .exe files directly anymore, and almost no email client will let you send one. So it'll still end up going in a zipfile at some point. If not in the official distribution, someone else will have to zip it if they want to share it with a friend. Convenience always comes at a price.
True. I wrote this to learn a bit of NSIS and to make uploading easier for me -- I don't want to have to download and extract Portable FileZilla myself, when this can do it for me. And in this case I don't really need persistent settings...
I realize there's a bit of controversy over this. This is just a project to let me learn a bit, so don't worry about whether you find it useful -- it's not going to be a big important thing.
~nm35
a.k.a. Mark
A single EXE would be much better for a quick connection. Let say this: You are on a Windows 2000 machine and you need to download a file quickly via FTP. However, Windows 2000 does not unzip ZIPs natively. You don't have any way to do this. You are stuck/screwed. Unless of course you pick up the handy Instant FileZilla, which requires no unzip and allows you to complete your business as you need to. And if you want to share your new find with a friend, you simply email them the link (which any email client does) and they too can enjoy the simplicity.
-Justin
Exactly. This isn't designed to replace Portable FileZilla, it's designed to give you a quick FTP session...
~nm35
a.k.a. Mark
Now that you clarified on that, it does make a bit of sense... still, USB keys are cheap enough that I really don't see this as much an issue. Just download PFZ at home and put it on your USB key (if you use FTP at all, you'll likely have already done this a long time ago), and then put the key into the Windows 2000 machine. Sure, some machines won't let you run applications off a removable drive, but chances are, if a machine is that locked down, it's not going to let you run some random program downloaded off the internet, either.
Just my two cents. I'm not trying to be mean-spirited or anything, so don't take it that way.
Just trying to be practical (sorry; I got that gene from my father. It's a blessing and a curse).