Iv'e been trying to set up an Ubuntu 18.04 as dual boot alongside my Windows 10 on my personal laptop, using this guide.

I have only one disk, so the first step is to shrink the current partition using Windows Disk Management tool. Iv'e disabled hibernation, paging and system restore, as i read that they are using unmovable files and could interfere.

But when i tried to shrink the partition, i received the following error:

You cannot shrink a volume beyond the point where any unmovable files are located. See the the "defrag" event in the Application log for detailed information about the operation when it has completed.


Notice that the disk management tool reports 0 space available to shrink. Iv'e seen that some users report that even though they have plenty of free space in their partition, they can shrink only some of it, but didn't find any users reporting that not space is available to shrink at all.

When checking for the defrag event in the Event Viewer, the following message appeared:

A volume shrink analysis was initiated on volume Windows (C:). This event log entry details information about the last unmovable file that could limit the maximum number of reclaimable bytes.
Diagnostic details:

  • The last unmovable file appears to be: \ProgramData\ESET\ESET NOD32 Antivirus\ScanCache\1183\468F805D0BD106D60386EA10EA96ADEC52285BBE.ahc::$DATA
  • The last cluster of the file is: 0x3b4e793
  • Shrink potential target (LCN address): 0x1875933
  • The NTFS file flags are: ----D
  • Shrink phase: To find more details about this file please use the "fsutil volume querycluster \?\Volume{1fed23cd-a012-4840-b65c-7be2904c9701} 0x3b4e793" command.

It seems to be related to my NOD32 ESET antivirus. When checking the folder (C:\ProgramData\ESET\ESET NOD32 Antivirus\ScanCache\1183) for it's contents, it's full (about 300MB) with similar files, that could not be deleted. Tried searching what is "ScanCache" in ESET forums and other resources, didn't find anything. Tried disabling Eset and changing folder permission, and then trying to delete - both didn't help, still couldn't delete the file.

Moreover, when i checked the disk usage with Piriform's Defraggler (for analysis purposes only), iv'e noticed that there's a "block" right at the end of the disk, after a continuous array of free space (about 130GB), which probably restricts the shrinking of the partition.


It contains the above mentioned file (468...5BBE.ahc), and many other files (if it's relavant, i can detail them). Iv'e read it's not safe/useful to use 3rd party defragmantation on SSD drives, so i didn't do that. And because some of these files are system files, i didn't want to delete them.

So my questions are:

  • Is there a safe way to clear that last block at the disk, which doesn't include deleting all the files?
  • Or there's a way to partition the disk in some other way?
  • Why the file system chose to place these files at that specific block?
  • And any other advice that might be relevant. Iv'e already check numerous guides and technical posts, didn't find anything that fit this specific problem.

Thank you.


  • Lenovo t450, intel i5 cpu, 8GB RAM
  • windows 10 pro 64 bit
  • SSD: samsung mzvlw256hehp-000l7 256GB

Edit #1:

Problem was partially solved. I'm posting my steps for future reference.

Iv'e found this link, where a user suggested using the CMD prompt of windows with the program "defrag" command (see microsoft doc). However, i didn't use the regular defrag option, but used the \X flag ('defrag C: \X \U \V'), which performs "Free Space Consolidation". I don't know if it's safe to use or if it can cause any damage like regular defragging, but i didn't find any resource suggesting that it could damage the system (one did state that it could be useless). It cleared almost all the files from that last block in the disk, and in general rearranged the disk so it have much less gaps. Below is the disk after consolidation and partitioning.


However, that last ESET file remained. Iv'e booted windows in safe mode and deleted it, even though it could cause damage. After rebooting again, windows and ESET worked fine.

I really don't know if both of these steps are safe or if iv'e caused any damage to the system or to the SSD. Anyway it works fine up until now and partitioning of 40GB succeeded.

  • Perhaps uninstalling some applications, such as ESET, repartitioning and then reinstalling would work. See techpp.com/2010/01/29/… for complete removal. Mar 17, 2020 at 21:37
  • Doesn't Ubuntu provide a utility to do this?
    – Phoenix
    Mar 18, 2020 at 1:18
  • @DrMoishePippik I thought about uninstalling ESET, but there 10's of other files in that block, at least some of them are windows system files, so i'm not sure that will help. And uninstalling ESET is apparently a lot of work...
    – juleand
    Mar 18, 2020 at 10:17
  • I am having the same problem with a file System Volume Information\{446e5e24-1971-11ec-9c34-a434d9168743}{3808876b-c176-4e48-b7ae-04046e6cc752}::$DATA Sep 21, 2021 at 4:44

2 Answers 2


Since it is an Samsung SSD, you could try the official tool (Samsung Magician) from this link


The documentation is full of blurbs, but it seems it could consolidate sectors. Don't do any other standard defrag on it, as the drive would literally read/write itself to death.

Appart from that, I generaly try to avoid partition resize on anything else, than fresh install. That would probably be the simplest way, risk free way by leaving space for the Ubuntu partition

  • Thanks, but unfortunately, the relevant functions according to their documentation: Diagnostic Scan and Over-Provisioning, are unavailable on this specific Samsung device. (message: The selected drive does not support this feature).
    – juleand
    Mar 18, 2020 at 9:20
  • 1
    Just to emphasize: DO NOT DEFRAG SSDs, EVER!
    – zx485
    Mar 18, 2020 at 21:00

Refer to this:

Before you can install Linux we must shrink the Windows C drive to make room for Linux.
There are two mutually exclusive ways to do this: Use Windows Disk Management
Use GParted, a utility available within the Ubuntu installation process.
If the Windows method has been used, GParted may not be available during the Ubuntu installation.
Each method seems to have its problems. The Windows Disk Management utility is perfectly safe but is likely to be unable to shrink the C drive to less than about 60 percent of a terabyte hard disk. That is because some files have been placed far out in the disk space and the Windows utility is unable to move them. (Strangely, the Windows defragmenter detects 0 fragmentation and is unable to move those files.) Moreover, using this method is going to complicate both preparing Windows to receive Linux and the installation of Linux. GParted moves those trouble-making files, can give Linux much more of the disk, and is very easy. There are concerns, however, that if GParted has been used, then when Windows 10 updates, it may damage the Linux partition. One Kubuntu user reports that Windows updates have twice destroyed his Linux partition. ( Post #7 in this thread: https://ubuntuforums.org/showthread.php?t=2385462) Unlike earlier versions of Windows, in Windows 10 it is not possible to completely turn off all updates, though it is possible to reduce them, as explained below.
- Ubuntu Wiki

If Windows is stubborn about moving those files, just go ahead with Ubuntu and use Gparted. Don't forget about turning off Windows Update, or reducing the amount of updates, otherwise Linux might get destroyed by Windows. Apparently in this thread: https://ubuntuforums.org/showthread.php?t=2385462, Windows cannot tell that the partitions are need for Ubuntu if you use Gparted, but it can tell if you use Windows Disk Management.

  • Thanks, this post was helpful. But again, users are reporting that windows 10 updates could not respect the partition created by Gparted, and i'm worried of the possible data loss.
    – juleand
    Mar 18, 2020 at 9:31
  • Would Windows then recogize the partitions if you used Gparted on Windows. It is compatible with windows. Also, you can temporarily cancel the installation: askubuntu.com/questions/279248/… It is safe if you resize this way according to this link, it will give an error, then chkdsk and update its record: superuser.com/questions/821131/…
    – Phoenix
    Mar 18, 2020 at 16:52

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .