XYcopy doesn't detect correct available space on mountpoints

[1024mb]

When we mount partitions to directories XYplorer shows the correct available space for the mount but when we copy or move files to it XYcopy detects the available space of the main drive where the mount point is created not the available space of the mount itself.
Basically:

dirve C, 40GB available
drive X with 500GB of free space
mount drive X to C:\mount
Copy 400GB of files to C:\mount
XYcopy warns about not available space detecting 40GB as the available space.
Also, if we accept, the XYcopy window keeps reporting 40GB as free space but it decreases it per-file and then resets back to initial value when each file finishes

XYplorer seems to report the correct free space.

[admin]

The next beta has an air fix (no time currently for reproducing).

[admin]

I assume the silence is a good sign?

[1024mb]

Sorry. I tried latest beta but it didn't work, XYcopy is reporting an incorrect free space not the mount's.

I tried copying a big file and the reported space was wrong, I don't know what is using because right now my C drive has 21GB free, the mount has 25GB free and XYcopy reported 30GB, I've noticed that upon cancelling very quickly the free space changes to that one of the C drive.

I have no drive with 30GB of free space.

[1024mb]

By the way, you can test this using VHDs, Windows allows mounting them in directories. You can create them from Disk Management.

[admin]

Just to be clear, XYcopy.exe is only used for background operations. I was investigating under the premise that it works in the foreground but not in the background. Is that the case?

[1024mb]

Yes, I have background processing enabled but I also have enabled "Use Custom Copy".
Even disabling background processing for copy or disabling it completely this still happens.

[admin]

So, this isn't about XYcopy. After your initial post, however, I found and fixed a bug in XYcopy, so your post was not in vain.

But did I get you right that the error even occurs when you completely disable Custom Copy? In that case, also the Windows shell does not see the available space which points to some issue in the mounting.

[1024mb]

So, this isn't about XYcopy.

I thought it was XYcopy since the reported available space in the XYcopy window is incorrect.

But did I get you right that the error even occurs when you completely disable Custom Copy?

No, you talked about the background operations, so I disabled "Background Processing" altogether but kept "Use Custom Copy" and this still happened. I only ever use "Custom Copy".
Also in Windows 10, Windows' transfer window doesn't show the current available space so I can't tell.

So to summarize:

• The XYcopy window shows an available space number that doesn't belong to neither the mount nor the drive where the mount is mounted.
• When copying files, XYplorer shows a warning about not available space because it uses the available space of the drive where the mountpoint is mounted instead of the available space of the mount itself.

[admin]

Also in Windows 10, Windows' transfer window doesn't show the current available space so I can't tell.

If Windows can't do it, then it's hard for XY to do any better. It relies on what Windows reports.

[1024mb]

This same bug is happening on normal network mounts.

On a linux server I have a folder on the root drive (let's call it /mounts_root) and I've mounted two other hard drives there, if I share this "mounts_root" folder through SMB and mount it on Windows on drive letter A, XYplorer reports the available space for A as the available space for the server's root drive, this is OK, but if I enter any of the two subdirectories, XYplorer keeps reporting the same available space instead that of the mounted hard drive. Kinda similar to what I reported in this thread. M$ File Explorer does report the correct available space for both of the subdirectories.

So to make it crystal clear, in M$ File Explorer "A" reports the available space for the server's root drive, one of the subdirs reports the available space of one of the hard drives and the other subdir reports the avail space of the other drive, whereas XYplorer reports for everything the same available space.

• On linux create a folder on the root
• Mount hard drives (or any other devices) to sub directories inside the folder created before
• Share the folder created in the root through SMB
• On Windows mount this share to a drive letter

[admin]

Hm, why shouldn't it work?

You can play with this script (replace "E:\Test" with your paths) to find out what works and what doesn't:

Code: Select all

echo get("freespace", "E:\Test");

[1024mb]

Code: Select all

echo get("freespace", "A:\");

61.02 GB

Code: Select all

echo get("freespace", "A:\drive_1");

61.02 GB

Code: Select all

echo get("freespace", "A:\drive_2");

61.02 GB

The drive mounted in "drive_1" has 5TB of free space, the one mounted in "drive_2" has 300GB, the server's root drive does has 61.02 GB free.

[1024mb]

For completeness:

Code: Select all

DIR A:\.*
 El volumen de la unidad A es zfs_datasets_alt
 El número de serie del volumen es: 931A-7395

 Directorio de A:\

17/09/2025  16:50    <DIR>          .
17/09/2025  16:50    <DIR>          ..
               0 archivos              0 bytes
               2 dirs  65,522,429,952 bytes libres

Code: Select all

DIR A:\drive_1\.*
 El volumen de la unidad A es zfs_datasets_alt
 El número de serie del volumen es: 931A-7395

 Directorio de A:\drive_1

17/09/2025  21:43    <DIR>          .
17/09/2025  16:50    <DIR>          ..
               0 archivos              0 bytes
               2 dirs  4,756,886,972,416 bytes libres

Code: Select all

DIR A:\drive_2\.*
 El volumen de la unidad A es zfs_datasets_alt
 El número de serie del volumen es: 931A-7395

 Directorio de A:\drive_2

17/09/2025  16:44    <DIR>          .
17/09/2025  16:50    <DIR>          ..
               0 archivos             0 bytes
               2 dirs   311,643,118,592 bytes libres

[admin]

Does this show the correct mount point (at "MountPoint: ...")?

Code: Select all

exist "A:\drive_1";