No permissions after moving file w/o "Copy NTFS permiss

[davop]

When moving file between two folders, NTFS permissions get reset (completely removed) on the file created in the target folder if "Copy NTFS permissions" option is not set in the move/rename dialog.

Expected behavior would be for the file created in the target directory to have inherited permissions from the target folder instead of no permissions. It is not possible to access the file after move unless permissions are explicitly set on the file.

Copy file dialog does not cause this problem.
TC7.50a does not have this problem.
TC7.55 final has this problem.

[MVV]

Cannot confirm. I copy/move files frequently and most of them w/o copying permissions - and I never seen such problem. I'm using TC 7.55 final.

Please describe source and target folder's permissions.

Can you reproduce this with another source/target folders?

[davop]

Correction, I tested this further...

TC7.50a and 7.55 have this problem.

TC6.53 does not.

Permissions on the target folder seem to be causing the problem.
In my test case they are set so that only my current user and SYSTEM have full permissions, other users including Administrator have no permissions.
In that case this bug is triggered while moving a file to such a restricted permission target folder.

I will also test further to clamp down possible causes of this.

In any case I believe the move operation should set permissions to default for newly created file in the folder as is the case when copying the file, and as it seems to be working in TC6.53.

[MVV]

Well, how can I reproduce this bug?

I created test folder, removed 'inherit permissions' flag and left only two users in access list - SYSTEM and <me>. When I move file to this folder it achieves inherited from this folder permissions and can be opened by me w/o troubles...

[ghisler(Author)]

2davop
Please send me detailed step by step instructions how to reproduce this error, e.g. which permissions I need to set exactly, and whether should move the file within the same disk, or from another disk (which is copy+delete).

[Dark-Star]

I had a similar problem on Samba4 shares once, but I didn't get around testing it. The problem was that when moving from Samba4 share to another dir on the same share, sometimes all permissions got lost. But not always. Moves in the same directory usually worked. Moves to some other parent directory had problems.
I never got around figuring out when *exactly* it happened.

Maybe I'll fire up my Samba4 server again to create test cases

-Darkstar

[ghisler(Author)]

On WinXP or newer, TC moves the file/folder, then copies the permissions from the parent to it. TC shouldn't do this on Samba drives, but they are very hard to detect because they report themselves as "NTFS" file system.

You can put XPMoveMethod=0 in wincmd.ini to avoid that TC tries to set the permissions of the moved file/folder from the parent. However, when you then move files/folders to different dirs on NTFS, they will keep their permissions. So when you move a file from one user's documents dir to another user's dir, the file would still belong to the first user.

[davop]

2davop
Please send me detailed step by step instructions how to reproduce this error, e.g. which permissions I need to set exactly, and whether should move the file within the same disk, or from another disk (which is copy+delete).

Here are detailed reproduction steps:

1. using clean Windows XP SP3 virtual machine
2. using user named "test" without created password
3. default TC 7.55 installation (next, next... finish)
4. create two directories
c:\test1perm [1]
c:\test2perm [2]
5. change folder option "Use simple file sharing" to OFF in Windows Explorer -> Tools -> Folder Options -> View
6. change directory [2] permissions in "Advanced Security Settings" (Properties -> Security -> Advanced -> Permissions)
6.a) REMOVE "Inherit from parent..." and select option "Remove", not option "Copy"
6.b) Add user "test" with Full Control BUT SELECT OPTION "Applies to" = "This Folder Only"
7. open TC with left pane containig directory [1] and right pane containing directory [2]
8. create test file "test.txt" with some text, in [1] and move it to directory [2]
9. verify that you cannot open "test.txt" in directory [2]
10. verify that "test.txt" in [2] has no permissions
11. Repeat steps 7. to 10. with Total Commander version 6.53 and compare results
File has permissions set and is accessible after moving it with TC 6.53

I believe the key component is in step 6.b) where you select that permissions apply only to "This folder only"
If you select "Applies to" = "This folder, subfolder and files" then there is no problem in TC 7.55

[EDIT]
After looking at my directory structure a bit more I found out another thing.
Assume you have:
c:\
c:\test2perm\
c:\test2perm\test3

Directory "c:\test2perm" has "Advanced Security Settings" for "test" user same as in example above but with:

1. "Apply onto" = "This folder, subfolder and files" [default setting]
2. "Apply these permissions to objects and/or containers within this container only" = SET TO ON
3. only "test" user has permissions on this directory

When option in 2. is set then subfolder "c:\test2perm\test3" had issues if a file is moved into it.
Subfolder "c:\test2perm\test3" needed no special permission changes after creation for this bug to trigger.

This is actually the situation that I had with my real data and after clearing flag under ""Apply these permissions to..." all seems to be well with move operations.

[ghisler(Author)]

This isn't a bug. As I understand it, the file "test.txt" only has the permission "inherit from parent". Since directory [2] is set to not inherit anything from its parents, the file will not inherit any rights. Since it doesn't have any rights by itself, it will not have any rights in folder [2].

This was changed from TC 7.5, where (by mistake) the inherit flag was always set when copying/moving.

[davop]

I agree. This is more of a feature than a bug.
Even when you move the file into directory [2] with Windows Explorer, permissions get copied instead of completely missing as would be the case with TC 7.5x - which might not be what you would want anyway.
In any case I think you can close this bug report now.
Thanks!