-Copy problem (permissions, network drive)

Lefteous · Post by *Lefteous » 2013-09-10, 09:26 UTC

1. I first tried copying a folder from a network drive (mounted into drive z:) to the program files folder on the local harddisk.
2. The copy failed and shows 'access denied" errors for every single file even when elevating the copy process.

Then I tried solving the problem another way:
1. I copied the folder to the desktop which is writable for the current user
2. Then I copied the folder from the desktop to the program files folder. It worked flawlessly (of course I had to elevate the process).

Any ideas?

Dalai · Post by *Dalai » 2013-09-10, 09:54 UTC

Every user has his/her own network drives - this applies to elevated processes, too. Network drives won't be available in the elevated copy process if you map a network drive as user XY.

Solution: Launch elevated TC instead of elevated copy process and map the network drive (again) and start copying afterwards.

Regards
Dalai

Lefteous · Post by *Lefteous » 2013-09-10, 10:16 UTC

2Dalai
Couldn't this be done by the elevated copy process?

Dalai · Post by *Dalai » 2013-09-10, 11:00 UTC

You are asking the wrong guy

. I don't know if it's possible and how much effort it would be to implement it this way.
I see two "handicaps" here (in case of unavailable elevation at least):

think of network shares that are limited to some users only.
think of network shares that require a (different) password to successfully map/login to.

So I don't think it's as easy as it sounds. But I will leave that decision to Ghisler, of course

.

Regards
Dalai

Lefteous · Post by *Lefteous » 2013-09-10, 11:32 UTC

2Dalai
What I don't understand is - why exactly is the elevated process unable to access the network drive? This should be the same user. For me it seems as if some elements of the user are not copied to the elevated process.

And of course I'm expecting a solution from Christian - but if you could help - even better!

Dalai · Post by *Dalai » 2013-09-10, 11:48 UTC

Lefteous wrote:What I don't understand is - why exactly is the elevated process unable to access the network drive? This should be the same user.

It is the same user name but with a different security token, so for Windows it's a completely different user with a different security context - and own network drives. That's not TC's fault, you can blame MS for this. I don't know if it was a design decision, but maybe they had some security concerns in mind (I don't know if there are any).

Regards
Dalai

Lefteous · Post by *Lefteous » 2013-09-10, 11:53 UTC

2Dalai
Yes and why isn't it possible to copy all this stuff to the elevated user?

Dalai · Post by *Dalai » 2013-09-10, 13:12 UTC

Well, it should be possible, but as I pointed out it might not be that helpful in some situations.

Regards
Dalai

Lefteous · Post by *Lefteous » 2013-09-13, 07:58 UTC

Why is this thread marked as not a bug?

Post by *ghisler(Author) » 2013-09-15, 12:02 UTC

Because it's not TC's fault: The network drive is only accessible by the normal user, and the protexted directory only by the elevated user, but none of them by the same user. Therefore it's not possible to copy files directly between these two locations.

Lefteous · Post by *Lefteous » 2013-09-18, 10:44 UTC

Explorer is able to do this job without problems (of course requires elevation). Why not TC?

Post by *ghisler(Author) » 2013-09-19, 14:00 UTC

Explorer changes files and folder permissions to do that - which is a bad idea because it defies the idea of protected folders.

Lefteous · Post by *Lefteous » 2013-09-20, 06:57 UTC

Yes changing permissions might not be a good idea. What about a two step process? Copy files to a local temp dir and then move them to the protected location?

MVV · Post by *MVV » 2013-09-20, 08:41 UTC

It would be faster to send files between TC and TCMADMIN through memory...

MarcinW · Post by *MarcinW » 2013-09-20, 13:59 UTC

...or even better - TC probably could create a file mapping and send the handle of this mapping to the TCMADMIN...