TC9.51 Bug: Move file (F6) in Unix/Linux

[11rui]

I have been having this extremely annoying issue for a while.
TC9.51 64bit on a Win64 system

On local drives, no issues.

On network drives (for work), however, I will always lose permissions after 'move/F6'. I can still see those moved files, but I lost most permissions: I can't read/write those files anymore. It keeps asking for administrator password, which I don't have. The only thing I can do at that moment is to delete them. I have lost few important files because of this problem.

I also tried to use move feature in windows explorer. No problem at all.


Any clue what caused this? any walk-around at this moment? F6 is a very common feature that I use daily. It hurts me so much that I have to pick up windows explorer after a decade of using TC exclusively

Thanks.
Ray

[11rui]

Forgot to mention that F5 still works fine. My partial 'solution' is to use F5 first and then delete original files. As you can clearly see, however, it's slow especially when I need to move big files (> 100 Gb). Not to mention I will sometimes accidentally press on the F6 key, and lose access to all those files ...

Let me know if you need any more info. Thanks.

[Dalai]

Well, the most important bit of information is missing: What kind of device are your network drives located on? NAS, regular PC, which version of Samba? That the latter is used is more or less clear since we're talking about Windows in conjunction with Linux.

Also relevant might be which copy method you're using, see Options > Copy/Delete. Might be worth testing with compatibility mode for network drives (\).

Regards
Dalai

[ghisler(Author)]

When TC moves files, it tries to update NTFS permissions when the source and target have different permissions. Of course this only works well with NTFS drives. TC therefore checks what file system a drive uses. The problem is that some Linux network drives report "NTFS" although they use something different like ex4 or so. TC tries to detect such drives by checking whether they support case sensitive names, but some Linux drives lie even about that.

Solution: You can turn this off, then the files will just keep their permissions. The downside is that when you move files between user accounts in c:\users then the files will still belong to the previous user.

Please add the following string to the file wincmd.ini, section [Configuration]:
XPMoveMethod=0

You can edit the wincmd.ini via Configuration - Change settings files directly.

[Dalai]

2ghisler(Author)
There's something odd about this configuration parameter. The help says

XPMoveMethod= [...]
Default: XP:1, other systems: 0

Now I don't assume the OP uses XP. What's the point of setting it to 0 when it already defaults to that? Either the help is wrong, or TC doesn't behave like it should.

Regards
Dalai

[Usher]

2Dalai
I suspect that 32-bit TC may work in Linux as in Windows XP. But it's 64-bit TC here and there is no modern 32-bit Linux…

[11rui]

Thank you very much for the solution! It works like a charm. Thanks !!!

I'm facing the exact situation you described: It's a linux system, but it's shown to have NTFS system as a mapped network drive.
Since I'm a regular user without administrator rights, I won't need to copy files between different user accounts


More details about my workstation:
Windows 10 Enterprise

Physical linux system:
GNU bash, version 4.2.46(2)-release (x86_64-redhat-linux-gnu)
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

Mapped drives are shown to have NTFS file system

[Dalai]

2Usher
As I understand it, the OP doesn't use TC on Linux but maps a network share as a Windows network drive provided by a Linux system. I don't see how it matters how TC would behave on Linux (running in Wine).

And since the configuration parameter seems to have changed things for 11rui, I really wonder if I understand something wrong or if there's an error in TC's help or TC itself. Let's hope Ghisler replies here again (because I don't get it).

And regarding the modern 32-bit Linux: Sure, Debian is also available as i386, and is likely to be the last one (of the major distributions) to end support for it. But as I said: That's besides the point.

Regards
Dalai