For rmdir, TScript::CreateFileList (fltDirectories) creates a bare
TRemoteFile with only its name and type: no directory list and no full
file name. TWebDAVFileSystem::DeleteFile takes the path from
File->FullFileName, and TRemoteFile::GetFullFileName then dereferences the
null Directory. With WinSCP 6.5.7 a script doing
mkdir /work/gone
rmdir /work/gone
over WebDAV fails with "Invalid access to memory" in
TRemoteFileList::GetFullDirectory (from TWebDAVFileSystem::FilePath,
TTerminal::DoDeleteFile, TScript::RmDirProc).
The entry now carries its absolute path, resolved as TTerminal::DoDeleteFile
resolves the same name. Protocols that use the file name (SFTP, SCP, FTP)
are unaffected; WebDAV now deletes the directory.
ec_cleanup frees every curve ecc-ssh.c sets up except Ed448: ec_ed448 lacks
the WINSCP_CURVE_CLEANUP its siblings have and ec_cleanup does not call it,
so its points and bignums leak at shutdown once an Ed448 key was used.
win_misc_cleanup frees get_system_dir's cached buffer but leaves the pointer
and its size, so a get_system_dir call after the cleanup returns freed
memory instead of fetching the directory again.
random_add_noise enters putty_section and then returns without leaving it
when the generator is not active. The section is recursive, so the thread
that returned keeps working, but any other thread entering it -- another
session's socket, RNG or bignum code -- then blocks for good.
aes-ni.c pushes its target attribute under #ifdef __clang__ but pops it
under #ifdef _WIN64. For clang targeting Win64 the two coincide. Otherwise
they do not: clang targeting 32-bit Windows (clang-cl in a WINSCP_VS build)
reports the push as unterminated and fails, and MSVC targeting x64 meets a
pop of a clang pragma it does not know (warning C4068). The pop now has the
push's condition.
memset takes the fill value before the size, so
memset(&ProcessEntry, sizeof(ProcessEntry), 0) zeroed nothing. It was
harmless, as Process32First fills the entry it reads, but the entry is now
cleared as intended.
FileGetSymLinkTargetSafe opens the link with CreateFile to read its reparse
point, but never closes the handle, so each call leaks one. DriveView calls
it for every symbolic link and junction it lists.
Seems to have no significant impact on release build (have some on debug build).
With 64-bit build, no impact at all. With 32-bit, there are some differences, but all seem to be in misidentified frames anyway (which are volatile, so the impact might not be due to change in sources)
Source commit: b8d538dd403c7f78778247278bed6e685a5589fb
includes: Fix two bugs in the JCLDebug address to source lookup
(though it does not seem to have any positive impact on exception stack trace collection)
Source commit: e49c36ce4a97a6eeb4a1f43743893fdab854ba50
https://winscp.net/tracker/2455
Some related refactoring:
Refactoring php release script includes
Reusing complete_translations in copy_complete_translations.php
Removing obsolete maketran.bat hack
Source commit: 07476ec822e4bd7b8b1c65ceb9783b6d92f20489
