Why is c:\temp_phw hardcoded?

[xrxca]

Why on earth is the default viewer using a hardcoded temporary directory named (c:\temp_phw) rather than one in the users temporary files folder? And worse than that why is it just assuming it can delete all files in that directory when it existed prior to the program being run. One of my techs discovered this and was seriously annoyed by it, her initials just happen to be PHW (she refuses to tell us what the H stands for) but she had a c:\temp_phw directory with some files in it that got hosed when we were testing the default viewer program. We have decent backups so I got her files back, but it's a pretty nasty bit of coding, and I would wonder how things would run on a system where permissions are locked down so the user isn't allowed to create a new directory in the root of C: ?

(And on an aside, if it IS going to toast all the files in the directory why doesn't it delete the directory as well?)

[bevtech]

that was a developers call and I am sure that he has he reasons. But another good question is why someone would name a personal temp with temp_phw instead of my files or phw_files..


I do recall that he had to do it for the copy and paste feature to work properly.

[mattice06082]

I think xrxca has a good point about users not having adequate permissions to create directory causing problems.

[bevtech]

I am not disagreeing that the temp dir should be created in the %temp% but we will have to wait for there explaination

[xrxca]

But another good question is why someone would name a personal temp with temp_phw

Or why they'd put it in the root of C:, believe me we've now had that conversation.

[bevtech]

@xrxca

Then they will complain when the files are not being backup. like you do not have enough to do but search for personal files stored on the root.. Should all be stored in my documents but people barely ever listen..

[xrxca]

I gave up a long time ago expecting files to be where they 'should' be especially when one mapping/geophysical app most of my clients use puts its data directory on the root of C: by default (We've now wrapped their install so when it's done the directory is moved to a better location, and it's config file is updated)

'User not developer' eh?
Around our office "USER" is considered a particularly vulgar slur

[bevtech]

well I am not a uvnc developer. I just try to assist other users and work on documentation.. You do have a very good point with the phw temp directory.. Maybe in the next version we can get that changed..

I am am forum moderator though so what out..

[Rudi De Vos]

On the PC A you copy a file c:\myfolder\
-then the full content of myfolder is zipped and send to B.
-The path in the clipboard of A need to be changed to the destination where B will extract the files.
-Clipboard is transferred to B
-zip file is extracted in c:\temp_pch, Clipboard reffer to the files in
c:\temp_pch

We current need to fix path to modify the clipboard content on A to
match the temp destination on B.
It can be changed, but a simple user selectable server path will not work.
Server and viewer need to negotiate the used path...
Perhpas when i have a lot of time left...

[X-Byte]

@Rudi De Vos:
Is there no possibility to work with the default Windows TEMP environment variable on the server and viewer side?

So a "fixed" path of %TEMP%\PHW_$sessionid would resolve to C:\Documents and Settings\UserA\Local Settings\Temp\PHW_56584 on PC A and C:\Dokumente und Einstellungen\NoobUser\Local Settings\Temp\PHW_56584 on PC B.

I know the %TEMP% solution was mentioned before, but I couldn't get the point why this shouldn't work? That's why I try to go a bit more into detail here.

Maybe the server really needs to know the absolute path of the viewer and vice versa to exchange file/clipboard information?

If so, exchanging the two different %TEMP% strings during the start of the connection phase shouldn't be too much of an effort (I hope
Adding a unique session id to the temporary path like PHW_C76FAB3 will also reduce the risk of killing unaffected data when cleaning up.

Or does this path really needs to be equal on both sides?

Then i fear there'll be no suitable solution for users with restricted rights.

BTW: Thanks for that great application

[karstenschilder]

@Rudi De Vos:
Or does this path really needs to be equal on both sides?

The answer is: no.

Else all other remote solutions (including remote desktop and remote assistance) wouldn't work, because they don't use a fixed temp folder. But in all of them you can use the clipboard feature.

The argument with zipping isn't correct. You can use a relative path in zip, like in all others.

[Rudi De Vos]

The only problem is that we need to exchange the %TEMP% between
server and viewer... in that case the c:\temp_pchw is not needed.

We could use %TEMP%\temp_pchw

In time of making, it was just a lot easier...and was runnning out of time.

[mstorman]

I modifed the server source and changed the temp path to be %TEMP%\temp_rs

And so far it is working without a problem.

Thanks,
Matthew.

[Rudi De Vos]

This is only used for filetransfer, possible will not longer work.