How can I manually move files on a physical hard disk? I want to move files which are never modified, only read, to the end of the partition, like movies or something.

  • If you're running windows 7 the regular defrag process will do a decent job of optimizing their placement. Without checking up on it, I think fragments of 64kb in size for large files will perform optimally even if each chunk is scattered all over the place. Not sure if the defragmenter worked this way in Vista as well. – Melikoth Sep 27 '12 at 12:04
  • You can create multiple partitions. One of them at the end of the disk. (Or at the beginning of the disk, whichever you define as the slowest part of the drive, since HDD speed is mostly irrelevant when you watch a movie). – Hennes Sep 27 '12 at 12:27

Firstly, excuse my English if it's bad!

You can achieve your goal of positioning rarely used files like video or music, with mydefrag scripting language.

By using its scripting language, you can create zones (in a partition with 3 zones, third zone is the end of partition) and place any specific files (choose a pattern like *.mp3 or *.avi) and move them to the end of partition by giving your personalized script to mydefrag software.


There are plenty of tools with direct disk access that will allow you to write raw data to the disk. On Unix-based systems, the command dd is usually available for that. On Windows, you'll have to rely on third-party software. You can write movies to the physical end of your hard drive that way and manually update the file system. On all but the most basic file systems, that would be quite a lot of tedious work and very uncommon outside the context of data recovery.

It is rather pointless, too. Defragmentation tools already do a reasonable job at moving files around to increase performance, and could easily undo your manual efforts. Disabling them would probably negate the performance benefits you are aiming for.

Nevertheless, there may be something to gain in storing infrequently accessed files on the slow end of your drive. The best way to achieve this would be to create seperate partitions, thus restricting where the files can physically go, similar to a technique called Short Stroking. Note that when the files are accessed on both partitions simultaneously, for instance when copying movies from one partition to another on the same drive, performance actually takes a severe hit due to the constant repositioning of the head.

  • Good advise. However, I won't call manually moving files pointless. – MC Emperor Sep 27 '12 at 15:19

Try Vopt defrag tool, by which after analysing drive you can manualy move files where ever you want at the end of the drive too.

  • 1
    I'm not sure if this is a useless answer, or a spam answer, but either way, it seems like something you ought to work on fixing. – HopelessN00b Sep 5 '14 at 6:12

Your idea was one of mine a time ago. But after a while a realized that the easiest and equally usefull way to do this is creating another partition and moving files to there. In windows 7 you can reduce the size of an existing partition, without losing contents, creating a new free partition. Of course, only if the first partition was not completely used. Better saying, if none of its files occupes a sector at the end of the partition. For example, if you have moved files to the end or partition, as using the sugested tools, you could not resize partition anymore. Sorry my english, I hope have been clear.

  • 2
    You don't really provide an answer that can be acted upon - it is mostly theoretical. – albal Aug 10 '15 at 1:48

Note: If you are not up to read all, go to final part where i say some tools that have "move to end of the partition"... but if you want to know why some ones claim it must be a must to be able to "move to" what ever we want to whtever place inside the partition, read it full.

Creating partitions is not an option on some cases, like having all the disk encrypted by VeraCrypt and you beeing paranoid... explication is...

  1. Paranoid = 100% Encripted and never ever put something on it not encrypted
  2. VeraCrypt System partition encryption does not allow it to be resized (at least yet)

Why a paranoid would never ever do the next steps:

  1. Decrypt the partition
  2. Resize the partition
  3. Encrypt the partition

The answer is: unencripted data was written to the disk, so it is recoverable (no matter if it is overwritted or wiped, etc).

Oh, yes, there are some companies that can recover the 100 last states of each bit of a HDD and also of a SDD, memory card, etc... so if you had your data in plain (not encripted) and you overwrite it 99 times, the non encripted data is still recoverable.

To do such, they unbox the disk and use low level atomic analizers and a super-computer to be able to know what was there before... a simple way to understand such could be (for a magnetic surface, for SDD and memory card is somehow similar):

  1. You have a 0 on the bit you are going to write
  2. You write on that bit a 1... the material rotates so it reads a one not a zero, but such rotation is not perfect
  3. You again write on that bit a 1... the material rotates a little bit more so it still reads a one, but such rotation again is not perfect (it is a little bit more rotated than previous one).
  4. You analize how much such rotation is and you can compute it is 1, prior to that must had been a 1 there (because of last little rotation) and prior to that must be a zero (because of final angle).

In numbers:

  1. Orientation = Horizontal = Bit is Zero
  2. Write a one, causes rotation to 60º = Bit is One (but it is not 90º)
  3. Rewrite a one, causes rotation to 75º = Bit is One (but it is not 90º)
  4. Rewrite a one, causes rotation to 80º = Bit is One (but it is not 90º)
  5. Rewrite a one, causes rotation to 83º = Bit is One (but it is not 90º)
  6. Rewrite a one, ... and so on ... it will never reach 90º

That final angle tells how many times a one has been written there.

Now imagine writes of mixed values...

  1. Orientation = Horizontal = Bit is Zero
  2. Write a one, causes rotation to 60º = Bit is One (but it is not 90º)
  3. Rewrite a zero, causes rotation to 30º = Bit is Zero (but it is not 0º)
  4. Rewrite a one, causes rotation to 82º = Bit is One (but it is not 90º)
  5. Rewrite a zero, causes rotation to 35º = Bit is Zero (but it is not 0º)
  6. Rewrite a one, ... and so on ... it will never reach 90º neither 0º again

Note: Such angle numbers ar ficticious, they are only just to show you a Zero and a One can have a lot of real physical positions of the materia that holds such data.

Of course... paranoid, really paranoid... recovering last 100 states costs near a billion of dollars, but can be done... and company says it can recover (on some cases, more states)... the dificoult part is to pair such changes... meant to ... one bit can be overwritten more times than another, so how to know which one was last written, previous write, previous to that... such is the top secret that company do not want to reveal (to not loose money income i think).

Now the bad NTFS implementation: NTFS native compression...

  1. Each 64KiB chunk is written on a multiply of 64KiB position, until a defrag enters in action... so if any 64KiB can be compressed to less than 60KiB+1B it will let a hole
  2. NTFS does not compress on RAM and store it contiguosly... the N*64KiB goes on the N*64KiB position, no matter if (N-1)*64KiB+1 to N*64KiB-1 could be compressed or not
  3. Result... a huge file of some GiB that can be compressed to a 50% would cause more than ten thousand fragments.

We all want two things:

  1. Put ISOs in non fragmented way
  2. Locate some files wherever we want (specially with non SSD, with normal rotating disk, where last part is normally less than a half on sequential speeds)

So... to speed up things... we all want... this:

  • Important files (small ones, ones accessed a lot on read but fairly rare on write) be at the fast part of the partition
  • Rarely accessed files and files that secuential speed is not critical (big ISOs, movies, music, etc) be at the end of the partition
  • written and modified files be in middle of the partition

So head track minimizes while start and end part will not be fragmented any more, so next defrags will be shorter.

Another reason to want such inside a partition:

  • Some programs have huge files (video encoding, etc) while working with a project (maybe some months of rendering, post production, translations, etc) and also have a long list of small pieces / small files (like sound effects injected on the stream design, etc)... all on the same folder (without subfolders)

For that ones that has sub-folders, there is the trick of hard/soft links (Junction / MKLink tools)... but for others, all files are on the same folder... doing one MKLINK per file is a total lost of time, also more... some files are created and deleted dinamically so links/junctions are not an option.

Oh, and you can also mount a VHD (XP & Vista with a tool, Windows 7 and up can do it directly from disk aministrator) on any NTFS folder... so a folder can be really a VHD file... but again we want such file on the begining or on the end of the disk... this time extension filter will not be able to know where we want it... same extension for both.

And there are so many ohter reasons... that i could be written for years and not finish.

Only way i found it really works perfect:

  • Program my own tool for such (i am so lazy i did not do such, i promes if i build it i will let it for free and OpenSourde)

Still searching for:

  • Find a tool / program that let you defrag the partition in a way that it let you specify a list of files / folders you want on the end part of the partition and which ones on the start of the partition.

Next best:

  • Find a tool / program that let you defrag the partition in a way that it let you specify a list of files / folders you want on the end part of the partition .

For that last option i had tried: WinUtilities DiskDefrag.

It is not fast at all, and it sometimes looks like glued on one file (hours to move a <1GiB file while with others >25GiB tooks a lot less)... maybe bad coded.

The other option i found (it requieres to learn LUA coding language) is: UltraDefrag.... (i am still trying to learn how to do it with LUA, i am noob on LUA).


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.