flat assembler
Message board for the users of flat assembler.
Index
> Projects and Ideas > Tray Defrag Goto page 1, 2 Next |
Author |
|
code_grinder 17 Dec 2007, 20:28
Hi everyone!
I have written a small defragmenter that resides in tray and scans in background all fixed drives. Almost doesn't load CPU, and defragments compressed files on NTFS correctly. Haven't tested it on encrypted files as I don't have them in the system, however code should work for them too. Have spent around two days on this project so far as I don't have much spare time . You can do everything you wish with this code, just mention me if you use it. Feedback would be appreciated.
|
|||||||||||
17 Dec 2007, 20:28 |
|
code_grinder 17 Dec 2007, 21:27
Have added popup menu on right click on tray icon. Previous version just exited on this event.
Edit: Updated package.
|
|||||||||||
17 Dec 2007, 21:27 |
|
vid 17 Dec 2007, 22:54
doesn't windows defrag silently when you do nothing?
|
|||
17 Dec 2007, 22:54 |
|
edfed 17 Dec 2007, 23:31
i think YES, but when doing a manual defrag, i always see that it's needed.
can you make it for FAT32? please.... |
|||
17 Dec 2007, 23:31 |
|
Madis731 18 Dec 2007, 06:21
@vid:
From Vista and on, its featured, but earlier than that - it didn't incorporate on-line defrag. @code_grinder: Isn't it using too much CPU in the idle loop? Last edited by Madis731 on 18 Dec 2007, 06:25; edited 1 time in total |
|||
18 Dec 2007, 06:21 |
|
code_grinder 18 Dec 2007, 06:22
Added speed up feature, useful if you wish to temporarily speed up defragmentation.
|
|||||||||||
18 Dec 2007, 06:22 |
|
code_grinder 18 Dec 2007, 06:40
Quote: Isn't it using too much CPU in the idle loop? It almost doesn't use CPU on my machine (Sempron 1.5 GHz, 512 RAM). How much does it use on yours and what is processor and RAM? I could make longer sleep in the idle thread. Edit: Here is version with increased Sleep parameter. It works almost the same on my computer.
|
|||||||||||
18 Dec 2007, 06:40 |
|
Madis731 18 Dec 2007, 07:21
The problem isn't with defragmenting - its always 0% then. But when it finishes, it goes to an infinite loop. On one of my machines its 451 files, the other one is some 10K... and its using 100% of one core.
Right-click > Exit doesn't kill it - I have to manually go to taskmanager... |
|||
18 Dec 2007, 07:21 |
|
code_grinder 18 Dec 2007, 08:18
Madis731 wrote: The problem isn't with defragmenting - its always 0% then. But when it finishes, it goes to an infinite loop. On one of my machines its 451 files, the other one is some 10K... and its using 100% of one core. That was silly bug, fixed. Here is update.
|
|||||||||||
18 Dec 2007, 08:18 |
|
code_grinder 19 Dec 2007, 06:37
Looks like there are no more bugs in the program . Here is little update which issue Sleep when finding place for file defragmentation (not much diffrence from previous version, just more correct way of doing things). Think if there will be no more bug reports, that will be the last change until New Year holidays. Have fun.
|
|||||||||||
19 Dec 2007, 06:37 |
|
edfed 19 Dec 2007, 06:51
Quote: It works already, program uses Defrag API that works both for FAT32 and NTFS. That means also that it will work only on NT systems, not 9x. no win9x ? |
|||
19 Dec 2007, 06:51 |
|
code_grinder 19 Dec 2007, 07:21
edfed wrote:
That's true. |
|||
19 Dec 2007, 07:21 |
|
edfed 19 Dec 2007, 07:25
|
|||
19 Dec 2007, 07:25 |
|
Madis731 19 Dec 2007, 08:52
I read your code but I couldn't find anything that is causing this, but on my laptops it still is rocketing the CPU-usage when it finished.
And btw, does it have to defrag *only* compressed files? Why not all? I think its time you saw my specs, because I haven't given you: Code: Windows Server 2003 Standard x64 Edition (Intel BTO) Intel T7200 CPU 1024 MB of RAM Seagate ST910021AS ;-AND- Windows Server 2003 Enterprise x64 Edition (HP nc6320) Intel T7200 CPU 2048 MB of RAM Seagate ST910021AS |
|||
19 Dec 2007, 08:52 |
|
codegrinder 19 Dec 2007, 09:23
Madis731 wrote: I read your code but I couldn't find anything that is causing this, but on my laptops it still is rocketing the CPU-usage when it finished. Have you got the latest version? Also I can give more detailed information in the tooltip about what program is doing right now, that we at least would know what piece of code is responsible for this. Madis731 wrote: And btw, does it have to defrag *only* compressed files? Why not all? It defragments all files. I wrote that it defragments compressed files correctly because I had problems with this just before first post. Madis731 wrote: I think its time you saw my specs, because I haven't given you: Thanks. However it doesn't look that machines are weaker then mine, so I don't understand the root of problem. I'll make version with more detailed info or maybe some logs. This will probably solve problem. |
|||
19 Dec 2007, 09:23 |
|
codegrinder 19 Dec 2007, 12:10
codegrinder wrote: I'll make version with more detailed info or maybe some logs. This will probably solve problem. Here is version with debug messages that can be catched by DebugView.
|
|||||||||||||||||||||
19 Dec 2007, 12:10 |
|
Madis731 19 Dec 2007, 20:03
Oops - I think 64-bit is to be blamed. The debug messages aren't caught and defrag never finished normally when exited (I discovered it just now - I need to terminate it from task manager).
These worlds (win32/64) are too different...I'll look into it tomorrow or on Friday... |
|||
19 Dec 2007, 20:03 |
|
codegrinder 20 Dec 2007, 10:56
The only thing I see that might be wrong is one-section structure, here is version with more classic section structures. Exe became a bit bigger of course .
|
|||||||||||
20 Dec 2007, 10:56 |
|
bitRAKE 20 Dec 2007, 17:48
I noticed you use EBX for 0 throughout the program. I don't know if this is a good assumption. Will windows always restore the process EBX before calling other threads within the process, and WndProcs? It is not my understanding that this is true, nor does the calling convention imply it would be so.
|
|||
20 Dec 2007, 17:48 |
|
Goto page 1, 2 Next < Last Thread | Next Thread > |
Forum Rules:
|
Copyright © 1999-2024, Tomasz Grysztar. Also on GitHub, YouTube.
Website powered by rwasa.