While moving a large amount of files between drives I got a message of not enough disk space left half way through moving the files.
It seems that Directory Opus does not check the copy/move destination if there is enough space left for the whole operation.
And after clicking "skip" DOpus even tried to move each remaining file in queue to fit into the remaining disk space.
This means it tries to fill the disk with each file and gives an error half way through, that it doesn't fit.
Why does DOpus not check the amount of free disk space prior to moving/copying?
Ist there an option for this? Do I miss something?
Most tools don't do this check, as it's actually difficult to do accurately and reliably and would end up wrongly telling you things can't fit sometimes, and failing to notice they can't fit other times. We'd rather not do something than do something that is unreliable.
You can add things to the status bar which show a graph of selected data vs space in the destination folder as a rough guide to help tell when you're selecting something that is much larger than the destination without having to look at the numbers. I think most people just look at the numbers, though.
Edit > Calculate Folder Sizes or Ctrl-L can be used to get the sizes of selected folders, and the status bar shows the total selected size and free space by default. But also remember that filesystem overhead is unpredictable, so one fitting into the other is only a rough guide, not an absolute. Sometimes you simply have to try the copy to see if it will work.
Some kind of indicator that the items to be copied might not fit the destination would be nice. There is no such thing up front and once your destination runs full, no proper way to skip or to abort and continue with another destination.
It must not be acurate to the last bit, since as you said precalculating this is not easy - if possible at all. But if file and folder counting is enabled and the total amount of data already known, a simple "amount > free-space" test possibly would not hurt?
Amount / free space is a little more complicated - files takes up more space that filesize shows - that depends on allocation unit size. BUT it's not that complicated either - filemanagers knows that type of informations (cluster size on source and destination drive; Opus has column "size on disk" so is already ready function) and recalculate number of files to number of clusters and then free space to free clusters. And based on that information, everything should be not that difficult.
There is workaround for that (not as perfect as cluster counting but still...). I always have filesizes and free space shows as bytes, so I can get sizes of all directories I want to copy before I start copying files (good that Opus do not need to counting that second time in most cases) and if I select all files and folders I want to copy, I see is copying possible or not.
If it would be my choice, I prefer to Opus made that calculations, especially that Opus have option "size on disk" so it can read how many bytes file needs to allocate. For computer is just a moment to made exact calculations, for user is almost impossible (if we're still talking about clusters).
If a file is small, NTFS can store the entire file, including the data payload, in the table of file names.
If a file has a lot of metadata attached to it, it might use more space.
The size of the name etc. metadata is unpredictable, with no API to determine it ahead of time. Ditto the maximum size of file that can be stored in the table alone. Ditto the actual cluster sizes, with some drives/filesystems that misreport that kind of information.
The end result will always be that if the amount of data you are copying is close to the amount of free space on a drive, then sometimes you would be told the data won't fit when it actually will, and sometimes you'll be told it will fit when it won't in the end.
It should be any nice and easy solution to do it, even more or less acurate. I assume that files with "lot of metadata attached" are just fraction of percent, so sometimes Opus calculate it wrong, but in 99% of cases it may work. I don't say it must have some priority but is nice moment to at least begin some beta function and improve it later.
There are some function in Opus that are not reliable and you fixing them to be more reliable. I see no problem to add one more for Zefiris. Of course with low priority. If I may choose - fixing my reported problems OR adding this feature - I strongly vote for leave this one for later.
You may look at it from another perspective:
What's the point of starting a copy operation if the data does not fit the destination?
Also consider the hassle with undoing what went wrong and having to start over again with another destination, time is lost on top of that.
A warning which might be incorrect about the data not fitting the destination is the smallest issue here.
It would allow you to rethink what you are about to do and maybe choose a destination which will definitely not fill up.
You also have the chance to delete stuff and see if you can "create" the required space in case you did not pay attention yourself early enough.
All this is much nicer than fighting the unexpected "disk full" requester and being stuck all of a sudden with only the skip and abort options.
I agree. I'm positively paranoid about "disk full" situations to the point where I will be absolutely certain there's enough space beforehand. I don't like being overly cautious like that, but it's how I've had to work around this.
Of course with low priority. 