Defraggler confused over compressed file sizes

[EclipseWebJS]

When files are compressed on the NTFS volume, Defraggler reports the true size of the files instead of the actual size that it takes up on the disk. Because later on during the defragmenting process it tries to move this big area of files, only to encounter that it has reached the end-of-file point laid out on the disk sooner than expected, and moves on to move the next file in line. This is exceptionally noticeable of large files, especially large text files whose sizes were about halved using drive-level compression.

[thany]

Confirmed.

 

I have a VM that's running eMule inside of it and all it's temporary/incomplete downloads are compressed files. That way, it's easy to get files that are like 600MB in reported size, but closer to 100MB on disk.

 

It's not a huge problem, just a bug that's hopefully easy to fix

[galileo]

3rd confirmation....Defraggler exhibits this behavior on large capacity drives with numerous large hard drive image files - say half a dozen ~ 5GB to 40GB files. The larger the file size the worse DF functions. Not only is the success of a defrag an issue, the length of time to complete a defrag is also an issue in that DF continues to try to move files around to solve (i.e. complete) the defrag "puzzle". The defrag cycle time can become rather longer that using Windows defrag - which actually seems to do a better job with the large files than DF....assuming there is enough free space for it to function.

 

BTW: This large file issue also seems to manifest itself on uncompressed drives as well. Even when there is more than adequate space for a complete defrag (say 70% free space), one stills ends up with fragmented files. Generally, a large file (say ~ 30GB) will frequently end up with 2 to 4 fragments after DF completes. As the file sizes grow larger, DF seems to be exhibiting both a less reliable (i.e. less successful) behavior and a notably slower behavior versus Windows defrag - or versus e.g. Diskeeper. This behavior does not seem to occur where the file sizes are generally below 1GB.

 

galileo

[Guest MrRon]

We will look into this issue

MrRon

[thany]

I just found out that the same issue is with sparse files. Less common, but from what I know, some BitTorrent clients (like uTorrent) create sparse files to save space without having to compress their files.

 

Like compressed files, sparse files also take less space on disk than they appear to do from a file manager. The difference is the way sparse files are stored: a sparse file only takes disk space for the parts that are actually written. So in the case of a download application, if a 1GB file (created as a sparse file) is downloaded 50%, it takes about 500MB of actual space on disk.

 

Luckily, a file cannot be both compressed and sparse (afaik)

 

I have not yet verified if encrypted files also show weird behavior like compressed and sparse files, but I suspect they don't, since their size-on-disk is the same as if it were a nonencrypted file.