This app has been released. Thanks for testing!
https://portableapps.com/news/2008-08-07_-_jkdefrag_portable_3.34
Application: JkDefrag
Category: Utilities
Description: JkDefrag is a disk defragmenter and optimizer for Windows 2000/2003/XP/Vista/2008/X64. This version also includes a GUI I wrote for it.
JkDefrag Portable 3.34 Pre-Release 5 0.74 MB, 0.99 MB installed
Besides the normal testing, i need confirmation that everything works fine on x64 systems and that it defrags with JkDefrag64.exe. I want people with external hdds to tell me if they were displayed by default.
If anyone can translate Italian or knows someone who can, please help correct the italian language file in App/JkDefrag/languages. Also, I will add support to any additional languages that translations are provided to me for.
Release Notes:
Pre-Release 5 (2008-06-09):
- fixed how 64-bit windows on IA64 processors wouldn't have been detected as 64-bit.
- fixed a bug where if some one in a million chance somebody ran JkDefrag off a CD with Notepad++ also on the cd then the View Log button wouldn't work.
Pre-Release 4 (2008-05-27):
- fixes a bug that occurred if a drive wasn't "ready", such as an empty floppy drive
- if run from a cd drive it now temporarily stores the log file in AppData to allow % Fragmentation to still be displayed
- a few misc improvements
Pre-Release 3 (2008-05-23):
- if JkDefrag process doesn't close it is now killed after the window is closed
- gui is now resizable
- small paf updates
Pre-Release 2 (2008-05-21):
Pre-Release 1 (2008-05-16):
Visit the Community page
Join our forums
Subscribe to our email newsletter
Subscribe with RSS
Follow us on BlueSky
Follow us on Facebook
Follow us on LinkedIn
Follow us on Mastodon
I've just tried it on my secondary drive on my Vista Ultimate SP1 machine, and it runs well and leaves nothing obvious behind.
[TRANSLATION]
VOLUME=Volume
FILESYSTEM=Système de Fichier
FRAGMENTED=Fragmenté
CAPACITY=Capacité
FREESPACE=Espace libre
ANALYZE=Analyser
DEFRAGMENT=Défragmenter
DEFRAGOPTIMIZE=Défragmenter et optimiser
VIEWLOG=Journal de bord
NOTANALYZED=Non-analysé
DEFRAGMENTED=Défragmenté
WAITING=Attendez que JkDefrag finisse de rouler en arrière plan
It shows both my internal partitions and external drive, but it doesn't show the fat32 flash drive it is running from. Is this a bug or is it not supposed to work on fat32 drives?
Other wise it works like expected.
take the JkDefragPortable.ini from the other folder and stick it in the root of JkDefragPortable folder,(where JkDefragPortable.exe is and the App, Data, and Other folders are) then open the ini and where it says "EnableFlashDrives=false" change false to true, but it is not really recommended to defragment flash drives.
An eye for an eye makes the whole world blind.
Mahatma Gandhi,
Indian political and spiritual leader (1869 - 1948)
yeah, i forgot to add that to the help... not that anyone would read it anyways. does anyone know if that info should go in the help.html in the package, or go on the JkDefrag Portable webpage?
I think it would be better to just put it in the help.html, because I know if I needed help on something from portableapps.com I would look at the help.html for answers on that program. Thats just my opinion.
An eye for an eye makes the whole world blind.
Mahatma Gandhi,
Indian political and spiritual leader (1869 - 1948)
This is AWESOME!! I love JKDefrag!
I am testing it now. It did recognize all my drives on startup (though I use a WD Passport as my flash drive). But it is FAT32 and it worked flawlessly. I love the interface you made also
Will report back with any issues.
Works well. Just an FYI, you are using the old splash screen image. John posted one with my updated icon included here. Do you need the ico file for this new version too?
The developer formerly known as ZGitRDun8705
thanks zach, i thought i was using the newer splash and i didn't even think to change the icon. i just made the new icon and i'll put it in with the next pre-release or official version
updated to Pre-Release 2. not a big update; see main post for changes.
But I made a grammatical mistake in my translation:
Instead of : FILESYSTEM=Système de Fichier
It's this: FILESYSTEM=Système de fichiers
Sorry !
http://fr.wikipedia.org/wiki/Syst%C3%A8me_de_fichiers
As you asked I tested jkdefrag on an old P3 with W2k. I marked three fat32 partitions to analyze. After analyzing the GUI window didn't reappear but the process was still there. After waiting a long time I killed the process.
The logfile is put into /App/JkDefrag directory. Shouldn't it be put into /Data ?
Besides this the GUI window isn't resizeable, so I had to scroll horizontally. Maybe you optimized it for English users, but German words tend to be longer than English ones
did the window come up after a few seconds telling you it was waiting on JkDefrag? I guess if sometimes JkDefrag won't close in the background, I can have my script try to kill the process. please test it again when i have implemented that into Pre-Release 3.
the logfile is deleted on exit of JkDefragPortable.exe. if you killed that process first it would have been left behind. John thought i should keep it as-is but idk since the log file is small and gets rewritten each time i don't see a problem with just leaving it in the Data folder; maybe i'll change it for the next release.
yeah i know the listview gets longer or shorter depending on the language. i made sure all the languages fit on the buttons but i figured the site was mostly english so it was okay if some users might have to scroll. i will work on getting it to resize though.
thanks for testing. i would much rather hear about errors in Pre-Release than the day of the official release which has been happening to me so far.
I have this same issue after doing an Analyze. The JKDefrag window disappears, but the process remains running and your GUI never comes back up until I manually kill the JKDefrag process.
The developer formerly known as ZGitRDun8705
did this just start happening with pre-release 2? because you reported it working fine before. or maybe you just tried it on a different pc. did the window come up like it is supposed to and tell you the gui is waiting on JkDefrag? anyways i guess it doesn't matter too much if it showed up or not because the next version will kill the process if the window is closed and it's still running. when i implemented the window to come up i was under the impression that it just took a little while for the jkdefrag.exe to finish doing something in the background but it doesn't look like it closes ever if that happens.
The GUI window didn't come up again. There were two processes left: JkDefragGUI.exe (11808 kB) and JkDefragPortabl (5112 kB).
The crashes not only take place when analyzing but also when defragmenting. Sometimes it even works as designed ... Sorry that I can't be more specific, I haven't found a reproduceable cause for those crashes.
hm... so JkDefrag.exe is closed and my GUI still doesn't come up? the only think i can think of to cause that is my script waits on the window titled "JkDefrag v3.34" to close before continuing so it wouldn't work right if it was somehow titled something else.
the only problem I have is it tends to freeze up if I swtich to a different window during analysis. I just get stuck with the please wait redrawing screen. Also a help guide to tell what all the different colors mean would be useful.
Release Team Member
well i was debating adding another html file in the app directory to be linked to from help.html but all the information like that is on the main JkDefrag website. tons of FAQ, colors, and helpful tips that may help your problem like:
Tip: Stop your real time virus scanner before running JkDefrag. Virus scanners check all disk activity, making defragmentation and optimization very slow.
Pre-Release 2 is working fine for me. Some small notes:
*Header 1 in the help.html says the version number is 0.4.1.
*Don't forget to add a homepage in the appinfo.ini
*Change AppSource.txt to read something generic like: "The source code for the base application is available from the portable applications homepage mentioned in the help.html file."
*In the Readme.txt, add a line about what EnableFlashDrives does and how to use it below the others in the ini section
That's all I caught. Excellent work on this app by the way. It's very well done, and nice and easy to use.
updated to Pre-Release 3. see main post for updates. this should fix any issues with the GUI not reappearing. if you had problems with this before please test this one and test it with 2 actions (ex: analyze c: then wait for the gui to reappear then analyze d: or c: again)
now i just need to contact avg, who is now giving a false positive on my exe.
Thanks for the new prerelease.
My first tests don't show GUI problems anymore.
And thank you for making the window resizeable
That would be AutoIT biting you in the butt.
Numerous antivirus programs routinely flag nearly all AutoIT programs as malware due to the fact that lots of malware is produced with AutoIT because it allows you to encrypt the script so it can't be read. And the fact that a "compiled" AutoIT executable is actually just the AutoIT exe with your script attached to the end of it. So the virus signatures for all AutoIT-based exes is nearly the same. This is one reason I've highly recommended against AutoIT for launchers. This is going to happen over and over.
Sometimes, the impossible can become possible, if you're awesome!
well the avg report lasted a day or two. i've never seen anything about script encryption besides upx. I'm pretty sure AutoHotKey gets false positives too and the language isn't as good. I'm not even sure if i can do some of the things my current script does in other languages (well not very easily at least). maybe i'll try learning a new language later on and port it but it's not a huge deal i don't think.
Travis,
In a sense it is a big deal.
AutoIt "is" used by the Blackhats and I don't like the whole "encrypt the script" thing at all.
I can not in good conscience blame my AntiMalware products/companies for seeing it with some suspicion.
If they find a lot of malware being written with it, and they are trying to be proactive, there are going to be false positives with every new AutoIt program that comes up.
As a norm I'm going to be avoiding apps that are written using it. I think it is best to take John's "guidance/recommendation" and try to avoid it if possible.
No reflection on you at all,
Tim
Things have got to get better, they can't get worse, or can they?
well autoit is used by malware producers because it is a powerful and easy to use language, not because it's a hacktool or anything. i will avoid it for any future things i write for this site. Are you aware though that both Xenon and EraserDropTarget also use AutoIt? and again, i'm pretty sure the "encrypting scripts" thing is just referring to using UPX.
Are you aware though that both Xenon and EraserDropTarget also use AutoIt?
Yes, I am, and as I said,
As a norm I'm going to be avoiding apps that are written using it
And again, this is no reflection on the authors of those apps in any way shape or form. If it's the only way they can do it than "Whatcha gonna do"? But if it can be done without it, that is what John is recommending.
Keep up the good work
Tim
Things have got to get better, they can't get worse, or can they?
AutoIT programs aren't compiled. It's really just the AutoIT runtime script and then your script is attached to the end of it and it's called the EXE you choose. AutoIT has a feature that lets you 'encrypt' the script so other people can't see what it does. The script attached to the end is encrypted using a private key and then decrypted by AutoIT at runtime. The key isn't public (AutoIT is closed source) so antivirus and antimalware software can't see inside to see if the script is malicious or not. Because you can't see inside the scripts or reverse engineer it, AutoIT is very popular with malware writers. And because it is used for lots of malware and antivirus can't analyze the scripts, you wind up with lots of false positives. This situation is unique to AutoIT because of the fact that it's closed source and has the script hiding feature.
Sometimes, the impossible can become possible, if you're awesome!
I'm pretty sure that NSIS is almost the same thing, because the UI is attached as an exe.
Insert original signature here with Greasemonkey Script.
NSIS is open source and doesn't try to hide what a script does. And NSIS is used by tons of large legitimate folks like Sun, Mozilla, AOL, Google, etc, so it's far less likely to have false positives.
Sometimes, the impossible can become possible, if you're awesome!
when I tried to UniExtract the labs talk it said it was an inno setup.
Insert original signature here with Greasemonkey Script.
I've just tried it under vista ultimate sp1, and it seems to work fairly well.
One very minor thing I noticed when I initially analyzed my c: the analyze window stayed open for about 15 or 20 seconds before it switched back to the gui
Also, AVG Free 8.0 flags i:\portableapps\jkdefragportable\app\jkdefrag\jkdefraggui.exe as a generic Trojan horse. I've already confirmed using clamwin that it's not a trojan, and I have made an attempt to report it (using the "send for analysis button in AVG's virus vault) but for some reason I keep getting a sending of sample virus failed error. I'll keep trying periodically to report it, but I figured I might as well mention all the issues I ran into.
15 or 20 sec before the JkDefrag window closed or after? as soon as the JkDefrag window closes the GUI should reappear (of maybe within a second).
avg no longer detects it as a virus anymore; now bitdefender does though.
it takes about 15 or 20 seconds after jkdefrag finishes analyzing the C: drive before it closes. The GUI itself does come up right away (within a couple seconds) as soon as the jkdefrag analyze window closes. The second time I analyze the c: it closes within a couple seconds and brings the gui right away, which is the same thing that happens with my D: drive.
My c: is a 160gb drive and my d: is 80GB, They're both western digital drives and both are formatted to ntfs
Also, you're right about the AVG thing, looks like they fixed it in this mornings definition update
ok well that problem is out of my control then; it's a problem in the main JkDefrag. I'm glad that the gui problem seems to be all fixed now though.
I figured it was something with jkdefrag itself and not something portable or with the gui but I figured I would mention it anyways in case it was something that could be cleared up.
Thanks for checking into it anyways.
I run it on Windows 2000,XP and Vista.
Works really Great!
EDIT:Oh, I almost forgot. When I try to defrag E:(which is a FAT32 drive), it tries to defrag A:.
hm... i can't imagine why it would do that. a few questions: do you have a floppy drive? did you enable flash media? does A: show up as a drive to defrag?
Well, I have a floppy drive and have enabled flash media but A: does not show up as a drive. Is that a problem?
Some flash drives can appear as multiple drives. I have one that shows up as F or whatever is the next letter *AND* drive A or B (whatever is free). Perhaps your drive is one of those but isn't quite showing up in explorer.
Sometimes, the impossible can become possible, if you're awesome!
ok, i just realized what the problem was. floppy drives only show up if there is a disk inserted and the way i have it coded it correlates the first selected drive with the first drive whether it was displayed or not. the first drive of type "removable" was the floppy so it used that letter instead of your flash drive. it's not a huge problem since most people won't enableflashdrives but i'm glad you caught it before the release so i can fix it.
Thanks, PR3 fixed the freezing issues I was having
The developer formerly known as ZGitRDun8705
I'll try to test it on my dad's slow PC.
Simplifying daily life through technology
updated to Pre-Release 4. i have a good feeling that this will be the last updated release before the official release.
Looks good from here. Once a few people test we'll push it out next week.
Sometimes, the impossible can become possible, if you're awesome!
Works well for me too. The freezing issue was gone in PR3.
The developer formerly known as ZGitRDun8705
Worked for me. However, this app does require admin rights, so I could not use it on my school pc.
Simplifying daily life through technology
I tried pre-release 4 last night, and it works well and leaves nothing obvious behind.
I tried the Pre-Release 4 and it worked good but anyway, but when I defraged my flash
drive, it didn't defrag. Instead it analyzed and all the files turned red.
Here's a picture:
http://www.wikifortio.com/207568/JkDefrag.gif
well red means it tried to move the files and couldn't so it labeled them unmovable. since it's a JkDefrag issue, the JkDefrag forums would probably be a better place to have the problem solved. the only thing i can think of is maybe if your drive is encrypted or something it may cause problems. defragging your flash drive isn't recommended anyways.
Was your flash drive write protected?
No, my flash drive was neither write protected nor encrypted.
you didn't have administrator access to the files.
You need to be on an admin account to use JkDefrag, or, rather, Windows insists that you have admin control of any files that you submit to its defragmentation API calls.
no, my gui prompts for admin rights if you don't have them and doesn't run without them.
Any way, I have admin rights.
(But when I run "S:\PortableApps\JkDefragPortable\App\JkDefrag\JkDefrag.exe" S:
it runs ok)
so it works when doing JkDefrag S: and not from my gui??? that would be weird since the gui is just typing the command line arguments for you. well the main button runs JkDefrag.exe -l "JkDefrag.txt" -q -a 3 S:
I'd say, it is strange, but it doesn't work that way. :-|
(or maybe me and my computer are weird)
why to defrag flash anyway?
it might be also that since the controller of the flash 'fragmenatates' all what is written there in a way so the cells are used equaly often, such defrag function can not be performed there.
I think there are lot of flash which do not have this function, but proper once should have it and there should not be a way for the user to write all his files to one corner of the flash and leave the other empty like we are used from the old hadrd drives to do so.
Otto Sykora
Basel, Switzerland
and in some circumstances, doing so can significanly improve performance.
Specifically, when writing data, ensuring that you can do so in large contiguous blocks can make the writes 10-100 times faster than if they are spread all over the device. This is beacause of the way controller blocks are -much- larger than file system allocation units.
The read performance increase is far more marginal, since flash has a close to zero seek time.
Oh, and wear levelling is a red herring - most (all?) controllers perform wear levelling across multiple very small domains within the overall flash device, in the order of a few tens of blocks with spares for rotation, not across the entire device.
Personally, I would recommend defragging a flash drive only when a visual check of the analysis shows that the free space is very, very scattered, or when almost all the files are badly fragmented.
For most users, even ones who use flash drives a lot, you're talking once every few months at most, compared to weekly or more for hard drives.
but also on the size of the whole memory chips behind it.
I found some flash (not those usb sticks) with no wear leveling at all, but those were some small units. Found also flashes with 128mb , yes small for today but with apparent wear leveling across whole mem chip. As we have no access to it except the manufacturer gives us hints and posibly software to work on the low level, we can not even know what is happening inside.
Otherwise I can not follow how a windows front end can have access to the internal structure of the data on the disk, if there is no access to such data anyway, except by very special software supplied by the manufacturer of the stick. From windows side there is no access to the real file structure on the flash and what ever is displayed by the controller is why the controller wants to be displayed to the external user.
If you want make sure that you can write in large blocks, then how do you know the controller will produce such blocks if you can only read what the controller allows you.
Otto Sykora
Basel, Switzerland
is how many controller domains are accessed by the write.
If the controller uses, for example, 64 kilobyte blocks, then when you write to the device, whether you are writing 1 byte, or 65,536 bytes, if they are all in the same controller domain, then it will take exactly the same amount of time.
To move this to a file system model, when you are writing the data to 4k blocks, if these blocks are consecutive (in their presentation by the controller to the usb subsystem), then 64k, although it is 16 blocks, will most likely be one or two controller domains, and thus take one or two time units to write.
If these blocks are non-consecutive, then they could be in as many as sixteen different controller domains, and thus take as much as 16 time units, or 8-16 times longer to write.
Defragging (and making the free space contiguous) maximises the chance that a large write will be to consecutive blocks, which maximises the chance that it will be to a smaller number of controller domains, which optimises the write performance.
The fact that the controller hides some of this behind such things as wear levelling is unimportant, since that does not generally cause it to cross domains.
You are quite correct that this is not an exact science, and I'm not suggesting that everyone can make their flash drives eight times faster by simply defragging them. But a badly fragmented flash is slower than an unfragmented one for writes (again, not noticably for reads, only writes).
For anyone who is interested, here is a link to Sandisk's wear levelling info clicky
>Defragging (and making the free space contiguous) maximises the chance that a large write will be to consecutive blocks, which maximises the chance that it will be to a smaller number of controller domains, which optimises the write performance.
Otto Sykora
Basel, Switzerland
saying that the controller will do what you see on your screen will mean that you can defrag any data written on the flash, regardless of file system on it or any other 'higher' organisation of the data.
This is not true, since all defrag software known to me will only work on standard filesystems like dos/windows or ntfs, but not deeper.
(as you can not defrag a linux partiton for example)
Otto Sykora
Basel, Switzerland
updated to Pre-Release 5 (very small update).
i am still waiting on at least one person to say if it works properly on a 64-bit windows. maybe nobody here has one
Can you specify what a 64 bit windows is?
Simplifying daily life through technology
well if you don't know, then you probably don't have it. Your operating system would either be 32-bit or 64-bit and you wouldn't have 64-bit without knowingly installing it.
I believe my dad's pc is 64-bit. I'll check tonight.
ok thanks. if not then it should still be okay to release w/o testing it. my code is correct so i would assume it would work properly.
Solaris any good for you?
I originally wanted to wait until it is final to use this defrager, but as you need Windows 64 Bit testers I better test it now...
hang on a minute and I tell you the result
Edit (1):
It asks for permission for admin rights (which is good) and defragments the drive just fine (according to its own log)
the defragment program is 64 bit, the GUI 32 bit (like it should I guess)
and it seems like leaving nothing behind but some logs from windows which show what apps I executed
I think the GUI could be improved, but whatever it seems like doing its job...
Edit (2):
I think any defragment program should move most files to the beginning of the drive, but this one don't... Bug or Feature? And if possible may include a option for that in the GUI... an a Legend in the defragment view to...
Another thing which is confusing is that the beginning of the drive seems like on the button where in any other program I know and used it was the other way around.
May be this shouldn't be mentioned here, but as you wrote the GUI I just wanted to let you know
<German>
"Sozialismus ist der Versuch die Gesellschaft mit
verordneter und erzwungener Freiheit zu unterdrücken."
(2007-07-24)
</German>
thanks a ton for testing! now i'm confortable with releasing it.
yeah the GUI could be improved; we are just keeping it simple for now. later on i will probably add an advanced options tab. i may even rewrite it in another language.
I'm using the Fast Optimization option.
"This optimization strategy is designed for every day use. It moves a minimum of data on the harddisk and finishes very quickly, but will not fill all the gaps on the disk. The strategy scans for gaps on the disk and fills them with files from above."
there are options to force everything to the front of the disk but it creates fragments and i don't see how it's needed unless you are wanting to shrink your partition. I can't really add a legend to the defrag window because that's not part of my program; i would have to have a window hover over it or something which wouldn't look good. The legend is on the JkDefrag homepage, but I will add the legend in to the help.html file now that you brought it up. i don't know what you're trying to say about the drive and button.
anyways, thanks again and i hope you find the program useful
The thing about the button is just a mistyping or my mind on a wrong track...
I meant _bottom_
anyway...
The point I wanted to make is that any other defragment program I know displays the first sector of a partition/disk on the top/first line of the window and fills it so that the last sector is on the bottom/last line.
Yours is exactly the other way around, which may confuses people...
And one of the reasons I want to have all data sorted to the front is to optimize VirtualMachine disk images
And I also wonder when I will released... nothing on the front page yet.
<German>
"Sozialismus ist der Versuch die Gesellschaft mit
verordneter und erzwungener Freiheit zu unterdrücken."
(2007-07-24)
</German>
The JkDefrag window visualization is part of the JkDefrag program, not the portable launcher. The launcher dev does not control it.
This Pre-Release 5 works well!
(Anyway,when will the program be offical?)
Now that we know it works on x64, let's get er done:
https://portableapps.com/apps/utilities/jkdefrag_portable
Edit away and we'll release tomorrow or Thurs.
Sometimes, the impossible can become possible, if you're awesome!
i've got the page done, but i'm not sure if the things i put under "Support" should be there or not. Also i added a color legend and corrected a reference to another program in the help.html file. here is an updated package: REMOVED
I've got it.
Sometimes, the impossible can become possible, if you're awesome!
It'll be nice seeing it on the applications page.
I've been waiting a while for this to come out. :-))
should this be supporting the future Language env variable for the menu? i didn't add it cause, well i didn't think about it, and also i've never seen any specifications on it, like the variable name and the possible outputss
It'd be nice to see those posted to be sure which variables are which. It's a hassle runnin' through different launchers to check.
No expert but used this on my 120 gig external HDD and worked well. Had to leave it over night to defragment and optimiz but noted improvement. Many thanks
PortableApps.com Advocate
Just figured I would post this in case it is helpful in some way. It is not a problem in the launcher as far as I can tell, it was a problem in JKDefrag. I ran it on my primary drive with no apparent problem. Then I ran it on my secondary drive, which has a few small files and then one really big image of the primary drive. I chose defrag+optimize. It ran for a while, and I saw the activity. After an hour or so, I looked at it and it it didn't appear to be doing anything. So I went to resize it and it put a message on there about program busy and didn't redraw the disk map. I left it for about 30 mins but no change. So I hit X. It appeared to close, but when I tried to re-run it, nothing happend. Looking further, I found that it was still running in the process list, using up 50% of CPU time in task manager. I tried to end task on it but it would not end, ever. I ended up letting it run over the weekend in case it really was doing something in the background. Today it was still running so I ended up rebooting my machine to get rid of it. The image file in question was 24gb, but it shouldn't have taken 72 hours to defrag it.
I am going to post this message on the JKDefrag forum as well.
Size limitation in Microsoft's defrag API maybe? JkDefrag is very simple in terms of actual defragging, as it uses MS's defrag API. I've never had a problem even with 6-8 Gb files. But I've never tried a 24 Gb monster.
I'm running Win xp pro x 64. I *think* (from the HD noise, and the text progress report at the top of the screen) that defrag is running properly, but the visual display is gibberish!
Richard
Richard
GM8CEA
the visual display shows you how the files on your hdd are laid out and the colors label the parts as fragmented, unfragmented, empty, unmovable, etc (color legend is on the jkdefrag homepage) and it shows the stuff being moved as it happens