file corruption while moving [F6] files within network drive

Please report only one bug per message!

Moderators: sheep, Hacker, Stefan2, white

Post Reply
lgillet
Junior Member
Junior Member
Posts: 3
Joined: 2016-05-10, 14:09 UTC

file corruption while moving [F6] files within network drive

Post by *lgillet » 2016-05-10, 14:23 UTC

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

User avatar
Dalai
Power Member
Power Member
Posts: 6451
Joined: 2005-01-28, 22:17 UTC
Location: Meiningen (Südthüringen)

Post by *Dalai » 2016-05-10, 14:45 UTC

  • Where and how exactly are the files corrupted? You can use TC's compare by contents feature to check that.
  • What type and size of files are we talking about?
  • Did you try a different copy method (see TC settings)?
  • Does TC move the file immediately (just changing the file's location) or does it copy the file and delete it afterwards?
Regards
Dalai
#101164 Personal licence
Athlon X4 880K, 16 GiB RAM, Gigabyte F2A88X-D3HP, Win7 x64

Plugins: Services2, Startups

User avatar
ghisler(Author)
Site Admin
Site Admin
Posts: 37013
Joined: 2003-02-04, 09:46 UTC
Location: Switzerland
Contact:

Post by *ghisler(Author) » 2016-05-11, 07:51 UTC

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.

You can turn this off via wincmd.ini
[Configuration]
XPMoveMethod=0

Then the permissions will not be touched when moving.
Author of Total Commander
http://www.ghisler.com

lgillet
Junior Member
Junior Member
Posts: 3
Joined: 2016-05-10, 14:09 UTC

Post by *lgillet » 2016-05-12, 12:04 UTC

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)

L

User avatar
Dalai
Power Member
Power Member
Posts: 6451
Joined: 2005-01-28, 22:17 UTC
Location: Meiningen (Südthüringen)

Post by *Dalai » 2016-05-12, 12:21 UTC

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!
Who's the owner of the file? AFAIK you can only change permissions if you're either the file's owner or root.

Regards
Dalai
#101164 Personal licence
Athlon X4 880K, 16 GiB RAM, Gigabyte F2A88X-D3HP, Win7 x64

Plugins: Services2, Startups

lgillet
Junior Member
Junior Member
Posts: 3
Joined: 2016-05-10, 14:09 UTC

Post by *lgillet » 2016-05-12, 15:24 UTC

Hi Dalai,

Yes, sorry I did not mention: I am owner of those files.

For the tests I mentionned, I even created the text file from my ssh session with vim. And yes, both on unix and on Windows10, I am logged in to the soNAS with the same user name and ownership rights.

The fact is that I need to pass *obligatory* through the windows>properties to re-set the permission rights is very weird. I should be both owning the files as much under windows as under unix...

Anyway, that's all I can report as the moment. I don't expect any fix in particular if Total commander is not the source of the problem.

But in case somebody freaks out because he/she gets "Can not open file XXX", then he/she might the solution by re-setting the permission rights under windows.

Thanks to all for your help,
Regards,

L

User avatar
ghisler(Author)
Site Admin
Site Admin
Posts: 37013
Joined: 2003-02-04, 09:46 UTC
Location: Switzerland
Contact:

Post by *ghisler(Author) » 2016-05-16, 09:08 UTC

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.
Author of Total Commander
http://www.ghisler.com

Post Reply