Total Commander

The disk is almost full. When I move files to the same disk, it says the disk is full and does not. But Windows does.

I cannot reproduce this here is what I tried:
1. Put some files on a USB memory stick until it was almost full (2.3MB free).
2. Created new subdirectory on the stick
3. Tried to move a file (about 50MB) from the current directory to that new subdirectory with F6
-> no error, the file was moved just fine.

Can you describe what you did to get the error, please?

My guess is that the files are still locked (open in another program) and thus TC copies them instead of moving them.

Regards
Dalai

And it only surprises me that the program was able to write a 50MB file without errors to the USB-stick with a free space of 2.3MB ???

AntonyD wrote: ↑2023-08-17, 06:39 UTC And it only surprises me that the program was able to write a 50MB file without errors to the USB-stick with a free space of 2.3MB ???

Move file at same disk

- within the same disk!

2Gral
For the process of moving we have to initially to copy this file
and only after that process - when we will get the confirmation that
the copy was done successfully we can and must to delete the initial file.
So obviously that for this process 2.3 MB of free MEM is not enough.

Or do you want to say that no copying is performed at all in this case?
only some file attributes in the file system change?
Well, then how do you check and trust this process? And how then can he even
potentially suddenly be able to give errors? If no change in physical blocks
does not happen on disk? WHAT is there to break then? But we know and see
right now that there are mistakes for such actions!

AntonyD,

do you want to say that no copying is performed at all in this case? only some file attributes in the file system change?

That is correct.

But we know and see right now that there are mistakes for such actions!

For example?

Roman

For example?

An example is the current topic itself, IMHO. And yes, I remember that sometimes I also encountered strange messages when trying to move something. So the essence of these error texts, which, if they can be displayed to the user, seem to have very little to do with the real nature of the problems that prevented this procedure from being performed at that "current" moment.

AntonyD,

An example is the current topic itself, IMHO.

That does not seem to be a problem of the basic mechanism of how moving within the same partition works, though.

Roman

2Hacker
I wrote about the messages that are issued by the system/Total for any errors associated with this 'move' procedure.
And as I wrote - the text of the error itself is very unrelated to the essence of the problem, which clearly exists/was on the OP's computer.
If we have learned that the MOVing process does not affect the very essence of the bits of the file image - the error with the text about the lack of free space is clearly not the error that can be understood in this situation.

If one understands the difference between moving files within one drive and between different drives, it's clear that in this case TC is trying to do the latter instead of the former (as Dalai already wrote - viewtopic.php?p=439508#p439508). Just treat moving within one disk as a rename, where path is subject of change instead name. Would you really expect that when renaming a file if e.g. 10 GB size, the original would be copied first and then deleted?

AntonyD,

the error with the test about the lack of free space is clearly not the error that can be understood in this situation

That is true. The question is, can TC determine all cases when the file is locked by some other program (as far as I know, e.g. Outlook uses some functions to only lock parts of its database file, which other programs have no official way of detecting, but maybe meanwhile something has changed)?

Roman

I'll freely admit that I don't know the exact procedure that is used to move a file, but I know for a fact that when moving files to a different directory on the same drive, the file is not copied to the destination and then deleted from the source. This can be easily proven by comparing the time it takes to Copy a large file (like 1GB), versus the time it takes to Move that same file. Copying the file will take at the very least, several seconds, complete with a progress bar that you can see updating. Moving that same file to another directory on the same drive will take about half a second. In fact, I just moved 3GB worth of files to another directory and it took less than a second.

Now that we've established that moving files on the same drive doesn't copy them first...

I have encountered this problem. There have been times that I have been saving picture files to an external drive and inadvertently filled it up to the point that there are only a couple megabytes left on the drive. I then try to move the files to a sub-directory on that same drive, and TC says that the drive is full.

If it's only changing pointers as to where the files are located, why should the amount of free space on the drive matter?

It even occurred to me that maybe since I'm moving them from the root directory into a sub-directory that maybe the extra characters in the path name are taking up too much space, but then I calculated that for the number of files I was moving, it should have taken up less than 100K. Also, if I move the files to another drive, delete them from the original drive, and then move them back to the sub-directory, they all fit.

So something strange is going on.

2Rekrul
When TC can't move a file within the same volume it will copy it instead and try to delete it afterwards. If it's still locked at that point in time, you'll get an error message. Try to move a (large) video file while it's being played in some video/media player. Then you'll see what I mean.

NB: This TC behavior is one of the worse and annoying ones, and I have complained about it several times; it should be configurable.

Regards
Dalai

When TC can't move a file within the same volume it will copy it instead and try to delete it afterwards.

This is done because sometimes a direct move is impossible, e.g. because the target and source are not on the same disk or partition (e.g. when using symbolic links).