You are here

WinSCP never saves temporary directory setting

10 posts / 0 new
Last post
j.smith
Offline
Last seen: 12 years 6 months ago
Joined: 2008-11-23 13:47
WinSCP never saves temporary directory setting

Using current PortableApps WinSCP 4.1.7.

In main launching window, select "Preferences" and beside "Other general options:" click on "Preferences...". In the new window, select "Storage", and the setting in question is under the "Temporary directory" section. This setting is tied in with the "Drag & Drop" settings as well.

I do not have the Explorer plugin installed (especially since this is supposed to be a portable app), so I cannot use the "shell extension" for Drag & Drop features within WinSCP. Instead, I have to set it to use a temporary folder to enable Drag & Drop features.

Since I use the temporary folder for Drag & Drop features, I have to configure my Storage settings and set my temporary directory settings correctly. By default the PortableApps WinSCP program sets the temporary directory setting to "Use this directory" with a value of ".\" for the current working dir.

Now, since this portable app is being run from my USB key (which may have a short lifespan compared to hdds), I do *NOT* want to use my USB key as the temporary storage location! Instead, I wish to use the systems temporary storage location ("Use temporary directory of system" setting). However, when ever I select that setting, click on OK and save the session settings as the default settings - upon re-launching WinSCP, the temporary directory setting is re-set to use the USB key.

This bug is quite severe, as it causes unnecessary read/writes to the USB key device which should not be used for temporary storage for the Drag & Drop features of WinSCP. Furthermore, having WinSCP use the temporary directory of the system should in fact be the default setting, even though leaving temporary files on the local system is something you try to avoid in a portable app.

j.smith
Offline
Last seen: 12 years 6 months ago
Joined: 2008-11-23 13:47
Small update to this

Small update to this problem...

Trying to override the setting with environment variables (using %DDTemporaryDirectory%) also does not work, as it seems the value gets changed after those are evaluated. I have also confirmed that both ini files have the correct (blank) setting for DDTemporaryDirectory. Currently my only solution is to set both ini files to the correct setting and mark them read-only. Doing so fixes the problem and also does not cause any errors on program close (having the ini files read-only used to).

Also, I believe this is a change introduced by PortableApps, as the portable U3 version of WinSCP mentions that it does in fact use system temporary storage locations, though I have not confirmed that to be true.

Simeon
Simeon's picture
Offline
Last seen: 9 years 12 months ago
DeveloperTranslator
Joined: 2006-09-25 15:15
Does this

still happen with the new version?

"What about Love?" - "Overrated. Biochemically no different than eating large quantities of chocolate." - Al Pacino in The Devils Advocate

j.smith
Offline
Last seen: 12 years 6 months ago
Joined: 2008-11-23 13:47
I just tried 4.1.8 and it

I just tried 4.1.8 and it still happens - it silently toggles the temp storage location to be the install path.

I should also note that my "fix" of setting the ini files read-only does have a draw-back... When you connect to remote systems and try to cache the SSH key, it can't because that data gets written to the ini file, so you constantly get prompted to cache the SSH key (and extensive timeouts of not clicking OK can disconnect you). The only solution to this is upon getting the cache dialog box, remove read-only from the ini file, click Ok to cache the data, then re-add the read-only setting.

I also noticed that it seems to log all session information to winscp.log even if logging is turned off - I had a 5mb log file. It shouldn't be doing this either.

ottosykora
Offline
Last seen: 1 week 4 days ago
Joined: 2007-10-11 17:48
most portable apps

are kind of trimmed so that they store all they can to the place they are installed. This is for most people not a bug but a feature, since they want touch the main drives as less as possible.

Do not worry about the extra writes to the flash, the current flash on the market seem to last for much longer then the mechanical connector placed on them. It is rather hard to impossible to destroy any cells by this little extra write cycles.

In fact yes, I manged to break some of them, but used to write heavy traffic all over the place on it for 2-3 years 24/7 operation. And those were built abt 4-5 years ago. The present one, you have no chance to replicate this any more.
The destruction by the use with portable apps etc is going into the class of urban legends.

Otto Sykora
Basel, Switzerland

j.smith
Offline
Last seen: 12 years 6 months ago
Joined: 2008-11-23 13:47
That may be the case, however

That may be the case, however the flash drive is MUCH slower than a HDD in access times, especially writes. If I am trying to transfer files to a remote host and they are first copied to the usb key before being sent over the wire, this is an extra bunch of writes and reads that shouldn't have to take place - it's a waste and it also slows down the transfer times - especially on large files.

Also, if I am transferring a file that is larger than the free space available on the usb key, then there's no way for that to happen if files are written to the usb key.

Again, I understand that sometimes this is a feature - however in this particular case, *forcing* files to be written to the usb key (as in, the PortableApps version tries to always set the option to write to the usb key) should be considered a bug, since it SHOULD be a configurable option that doesn't get overwritten on launch.

ottosykora
Offline
Last seen: 1 week 4 days ago
Joined: 2007-10-11 17:48
hmm, but

so far I checked, when I try to send file from hd, there is no problem in writing it to the apps dir first. It looks this is happening on download only.

But then: system temp might be ok to be permanently set, but probably not for most people. It could be forgotten in that position and problem is here, the software will do work on the host drive which is normally not wanted with portable apps.

This is probably why it jumps to default value on start up, otherwise you would have to have warning for the user . attention, you are not in portable mode now.

I am also not sure if the system temp will be called up in all suitable OS similar way, so once set, it under circumstances might not work on other place.
If you use it on the same place, well then you might install it locally as well.

Otto Sykora
Basel, Switzerland

j.smith
Offline
Last seen: 12 years 6 months ago
Joined: 2008-11-23 13:47
I agree to some points - the

I agree to some points - the setting shouldn't be changed by default. Upon initial install of Portable WinSCP, I agree that having it set to use the usb drive as its storage location is good for true portability, however allowing the option of using the local PCs temporary storage location as an alternative should be allowed - and there doesn't need to be a warning about changing the "portability" of the application because this is purely just for supporting Drag & Drop download functionality of the application which doesn't affect it's ability to be "portable".

The *only* thing the setting changes is that temporary downloads are now stored in the system temporary directory (which is auto-detected by WinSCP so no further coding needs to be done about that either - it's an ENV variable in all versions of Windows, even as far back as 3.1).

Regardless of how you use WinSCP, switching to using the systems temp storage dir has the *only* drawback of writing data to the PC. If you trust the PC enough to store data there, then there should be no reason to not allow this functionality. I should also mention that if you've ever used U3 software - it's potentially "worse" in how much data is written to the local PC... it actually extracts your apps to the local system and runs them entirely from there... allowing registry writes and everything... its just supposed to be written in to the U3 programming that it erases its tracks when you "eject" the U3 device. So allowing WinSCP to write some temp data to %TEMP% is hardly a deviation from calling it "portable" if you consider anything U3 as portable.

So, yes - don't change the default configuration, but allow us to permanently set WinSCP to use the local systems temporary storage directory instead of the usb drive.

ottosykora
Offline
Last seen: 1 week 4 days ago
Joined: 2007-10-11 17:48
tested just now

installed portable winscp on stick of 128mb.

Transfered file of 720mb with default setting. But you said this is not possible?
Works perfect here on XP sp2.

Tried to download the same file again. No problem works nice.

Tried to observe any changes, ok, this is not easy from the windows env alone, but so far did not see any extra writing to the stick or to the winscp folder.
Where did you see lot of writings and whole files to be copied to? Can you give the position where, which folder etc did it happen?

I could not see just now anything problematic, but I might be looking in the wrong place.
Can you give some more infos?

And also I am not sure I understood what you mean by the speed of upload and speed of writing to the stick.

My slowest stick does write with abt 2mb per second, reads abt 5mb per sec.
But my ADSL connection at home is only 0.3mb /sec and at the office I have abt 1mb /sec maximum what they give me. This is average connection speed I think when it comes to communication with outside world and not internal gigabit ethernet.

So how does it happen that your stick is slower then the internet connection on your provider?

Sorry but just curious, not sure I understood all you mentioned here.

Otto Sykora
Basel, Switzerland

j.smith
Offline
Last seen: 12 years 6 months ago
Joined: 2008-11-23 13:47
I suppose I should have

I suppose I should have mentioned that it was only speculation that a file larger than the free space on the usb drive wouldn't work. It mentions that it writes full files and then moves them to the destination, so it *shouldn't* be able to work - which was why I mentioned the possibility of the problem.

It has been a while since I last tested this, but I believe it's an issue on download only (the description of the Drag & Drop functionality mentions downloads only). I also believe that *if* it does copy files to your usb drive, there is a folder it creates under the Data folder.

I noticed the writes first when I was doing downloads and my usb drive has a blue light that blinks on disk access - it was doing a lot as I was downloading a large file. There was, for certain, usb disk writing happening as I was downloading the file - it was indeed writing it to the usb drive and upon download completing, would move the file from the usb drive to the actual destination on the PC.

As for speed of writing to the usb stick, I have one that is rather slow (I don't know actual speeds, but compared to some Sandisks I have, it's noticeably slower). I have a faster connection at 10mb down, and there are people in the US with 20+mb connections. The true speed problem though is the copying from usb stick to final destination that is what slows things down. If I have a 200mb file that it temp stored on my usb key, it has to read that (at usb key speed) to write to my PC - whereas if the temp file was on my PC already, it's just HDD read/write speeds.

Log in or register to post comments