Hi,
I will try to explain the problem:
I am connected to an IBM soNAS through the windows "Map Network Drive". The network drive is open on both left and right panels in Total Commander. When I try to move (with F6) a file between 2 folders in that soNAS I get a file corruption. It seems that the copy (with F5) works flowlessly, but just the "move" seems problematic.
I tried the same (moving files) between/within local drives and between network drives and it seems to work fine as well. I even can move files within an older userNAS mounted also as network drive. No need to say of course that the movefrom Windows file explorer (Win 10) luckily worked fine for the same folders/files.
So I wonder if this could be a specific problem with the file system used in the IBM soNAS or whether this is indeed a bug of Total Commander?
PS: luckily, this did not cause any damage because I had still another backup of the files, but really all my files moved this way got corrupted (I could not open them at all anymore).
Just wanted to report, in case this happens to somebody else...
Thanks in advance for your help,
L

F6 just uses MoveFileEx, a standard Windows function. I don't know how this can cause file corruption. However, TC tries to set the permissions to those of the target - maybe this makes the files inaccessible depending on the permissions of the target folder.

Hi,
thanks to both of you for the reply.
I digged this a little deeper and, yes indeed, this is a permission issue.
But I still still there is something *really* strange going on with "move".
Here are my tests:
1) copy [F5] a file to a different directory on the same soNAS => OK
2) copy [F5] a file with "copy NTFS permission option" to a different directory on the same soNAS => PARTIALLY OK
3) move [F6] a file to a different directory on the same soNAS => NOT OK
4) move [F6] a file with "copy NTFS permission option" to a different directory on the same soNAS => OK

So yes, Christian is right: my first assumption that the file was corrupted was wrong: the file permission had just disappeared!! Actually it changed from -rwx------ to ---------- (checked with ssh/unix terminal), so it could not be open even from within windows10.

Now here is the weird part: back to ssh/unix, changing the file permissions of the test 2 and test 3 (e.g. chmod g+r) does not work anymore!? While it works for options 1 and 4!

For option3, here is how I proceeded to get access back to my file: Edit the file permissions from windows10 directly (via Properties>Security). There you see the following message: "No groups or users have permission to access this object. However, the owner of this object can assign permissions.". Then you can "edit>add>advanced" to add myself/user. HOWEVER, though the permission (seen from ssh/unix) are now fine (-rwx------), here again you cannot change them anymore with ssh/unix (i.e. "chmod g+r" won't work). But at least, you can still get access back to read your files!

In summary: these are the option that work for me:
- Copy *WITHOUT NTFS permission*
- Move *WITH NTFS permission*

While the other two (copy with NTFS permissions and move without NTFS permissions) do not work properly.

I hope I was clear with my steps (that was a pretty complicated one to explain). I don't think Total Commander is necessarily "guilty" but doing the copy and move tests from within Win10 does not break the change permission (chmod) capabilites of the files in follow-up ssh/unix steps. So maybe there is something different in the way total commander is handling the copy and move function with and without the NTFS permissions?

Hope that helps

And thanks for the great software (I am back to it on Windows10 after many years of Mac and it is great to use it back)

The problem is that these drives are reported as NTFS, but do not correctly implement the NTFS permissions. So when TC tries to read the permissions of the target and set the file permissions to it, you will get invalid permissions.

This problem doesn't exist when copying because a NEW file will be created which automatically inherits the target folder permissions. But when you move a file, it will not inherit the permissions of the target, but keep its original permissions. That's why TC tried to update the permissions after moving the file.