info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
FTP Rename File Error 12003 WinInet
800 views
Skip to first unread message
Arne Ortlinghaus
Dec 13, 2013, 9:52:35 AM12/13/13
to
Hello,
since few days we have errors in the FTP export with the CFTP classes when
using the renaming of the file. We use renaming of files to be able to send
an entire file with a temporary name without giving the receiver the risk to
open a file that is partially transmitted.
It seems that this is an error (or a problem) introduced in the Wininet.dll
with the update to Internet Explorer 11. (Google f�r ftp rename file 12003
or ftp rename file 12003 ie11 site:microsoft.com)
Until now I have no work arounds other than ommitting the renaming and
sending directly the file with the final file name.
May be some of you will have the same errors.
Arne Ortlinghaus
ACS Data Systems
since few days we have errors in the FTP export with the CFTP classes when
using the renaming of the file. We use renaming of files to be able to send
an entire file with a temporary name without giving the receiver the risk to
open a file that is partially transmitted.
It seems that this is an error (or a problem) introduced in the Wininet.dll
with the update to Internet Explorer 11. (Google f�r ftp rename file 12003
or ftp rename file 12003 ie11 site:microsoft.com)
Until now I have no work arounds other than ommitting the renaming and
sending directly the file with the final file name.
May be some of you will have the same errors.
Arne Ortlinghaus
ACS Data Systems
D.J.W. van Kooten
Dec 13, 2013, 11:08:47 AM12/13/13
to
On Fri, 13 Dec 2013 15:52:35 +0100, "Arne Ortlinghaus"
<Arne.Ort...@acs.it> wrote:
Hello Arne,
truncated for almost any file size except very small, with a few 100
bytes. This started after an update to Windows 8.1 but I can imagine
that an Explorer 11 may have the same problem.
As we did have the so called Chilkat libraries, we replaced our FTP VO
exchanges with these of Chilkat, with the added bonus that we can show
a nice progress bar + remaining upload time and it works asynchrone
(we can continue doing other things in the program).
If it's really a VO thing (more non VO programs suffer from the bug
too) forget about a patch. VO maintenance doesn't have priority
anymore....
Dick
<Arne.Ort...@acs.it> wrote:
Hello Arne,
>
>since few days we have errors in the FTP export with the CFTP classes when
>using the renaming of the file.
>since few days we have errors in the FTP export with the CFTP classes when
>using the renaming of the file.
>It seems that this is an error (or a problem) introduced in the Wininet.dll
>with the update to Internet Explorer 11. (Google f�r ftp rename file 12003
>or ftp rename file 12003 ie11 site:microsoft.com)
I am not sure if this is the same problem we had: FTP uploads were
>with the update to Internet Explorer 11. (Google f�r ftp rename file 12003
>or ftp rename file 12003 ie11 site:microsoft.com)
truncated for almost any file size except very small, with a few 100
bytes. This started after an update to Windows 8.1 but I can imagine
that an Explorer 11 may have the same problem.
As we did have the so called Chilkat libraries, we replaced our FTP VO
exchanges with these of Chilkat, with the added bonus that we can show
a nice progress bar + remaining upload time and it works asynchrone
(we can continue doing other things in the program).
If it's really a VO thing (more non VO programs suffer from the bug
too) forget about a patch. VO maintenance doesn't have priority
anymore....
Dick
Sherlock
Dec 13, 2013, 10:42:40 PM12/13/13
to
snip[ It seems that this is an error (or a problem) introduced in the Wininet.dll with the update to Internet Explorer 11. (Google f�r ftp rename file 12003 or ftp rename file 12003 ie11 site:microsoft.com)]
There is a known an unfixed bug in Wininet with Active/Passive relating to doing things in the same connection. If open an close the connection the same parameters you probably find it works.
I had a situation when I try and set oFTP:SerCurDir() then oFTP:Directory() and it would not return a array of files in the FTP Directory() call. By issued a oFTP:CloseRemote and oFTP:ConnectRemote() and then oFTP:SetCurDir() and oFTP:Directory() it would work.. and from memory was fine on Active FTP verse Passive FTP connection.
I would not be surprised you are affected by the same problem.. which is not VP FTP bug but a known MS bug.
Phil McGuinness
There is a known an unfixed bug in Wininet with Active/Passive relating to doing things in the same connection. If open an close the connection the same parameters you probably find it works.
I had a situation when I try and set oFTP:SerCurDir() then oFTP:Directory() and it would not return a array of files in the FTP Directory() call. By issued a oFTP:CloseRemote and oFTP:ConnectRemote() and then oFTP:SetCurDir() and oFTP:Directory() it would work.. and from memory was fine on Active FTP verse Passive FTP connection.
I would not be surprised you are affected by the same problem.. which is not VP FTP bug but a known MS bug.
Phil McGuinness
Karl Faller
Dec 14, 2013, 3:45:30 AM12/14/13
to
Dick,
really MS who srewed big time ;-(
Karl
>>with the update to Internet Explorer 11. (Google f�r ftp rename file 12003
>If it's really a VO thing (more non VO programs suffer from the bug
>too) forget about a patch. VO maintenance doesn't have priority
>anymore....
following your link it seems that Vo has nothing to do with this, it's
>too) forget about a patch. VO maintenance doesn't have priority
>anymore....
really MS who srewed big time ;-(
Karl
Wolfgang Riedmann
Dec 14, 2013, 3:32:26 PM12/14/13
to
Hi Arne,
> since few days we have errors in the FTP export with the CFTP classes
> when using the renaming of the file. We use renaming of files to be
> able to send an entire file with a temporary name without giving the
> receiver the risk to open a file that is partially transmitted.
I have FTP writing problems on machines with IE 11 (both W7 and W8.1).
Sometimes the files were written only partially, and sometimes (when
transferring a lot of files) the write returns errors and and the
connection is closed.
Because of this, I had searched a FTP dll and found Marshallsofts FTP
Client Engine, a small and fast C DLL, and not too expensive (I'm using
the SMTP library from Marshallsoft instead of VOs SMTP classes because
of the problems with attachments over slow and instable internet links
like UMTS connections).
Wolfgang
P.S. if someone is interested, I can share my interface code
--
> since few days we have errors in the FTP export with the CFTP classes
> when using the renaming of the file. We use renaming of files to be
> able to send an entire file with a temporary name without giving the
> receiver the risk to open a file that is partially transmitted.
Sometimes the files were written only partially, and sometimes (when
transferring a lot of files) the write returns errors and and the
connection is closed.
Because of this, I had searched a FTP dll and found Marshallsofts FTP
Client Engine, a small and fast C DLL, and not too expensive (I'm using
the SMTP library from Marshallsoft instead of VOs SMTP classes because
of the problems with attachments over slow and instable internet links
like UMTS connections).
Wolfgang
P.S. if someone is interested, I can share my interface code
--
D.J.W. van Kooten
Dec 16, 2013, 5:32:15 AM12/16/13
to
On Sat, 14 Dec 2013 09:45:30 +0100, Karl Faller
<mail_withoutthat_@_drei-f_andthat_.de> wrote:
Hello Karl,
>following your link it seems that Vo has nothing to do with this, it's
>really MS who srewed big time ;-(
>
That's certainly true but on the other hand, I found only a few
reports that it went wrong, e.g. see my post (2 reactions with the
same problem):
http://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/
a938b6ad-b1ae-4d50-83c2-4b61e5633e32/ftp-not-working-since-windows-81?forum=windowsgeneraldevelopmentissues
So my guess is that VO uses some outdated functions using the
wininet.dll which causes the problems. The majority of FTP programs do
not seem to have the problem and Microsoft seems not in a hurry to
repair.
Dick
<mail_withoutthat_@_drei-f_andthat_.de> wrote:
Hello Karl,
>following your link it seems that Vo has nothing to do with this, it's
>really MS who srewed big time ;-(
>
reports that it went wrong, e.g. see my post (2 reactions with the
same problem):
http://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/
a938b6ad-b1ae-4d50-83c2-4b61e5633e32/ftp-not-working-since-windows-81?forum=windowsgeneraldevelopmentissues
So my guess is that VO uses some outdated functions using the
wininet.dll which causes the problems. The majority of FTP programs do
not seem to have the problem and Microsoft seems not in a hurry to
repair.
Dick
Karl Faller
Dec 16, 2013, 5:19:09 PM12/16/13
to
Dick,
not correct to "kill" them without any notice.
>The majority of FTP programs do
>not seem to have the problem and Microsoft seems not in a hurry to
>repair.
maybe i'm getting paranoid, but can't help to think, that again a
established way of communication gets killed to urge people to use
some "cloud" based thing, where MS, or NSA or whoever may listen as at
will...
Karl
>So my guess is that VO uses some outdated functions using the
>wininet.dll which causes the problems.
Even if these hypothetical funcs were marked as depreciated, IMO it is
>wininet.dll which causes the problems.
not correct to "kill" them without any notice.
>The majority of FTP programs do
>not seem to have the problem and Microsoft seems not in a hurry to
>repair.
established way of communication gets killed to urge people to use
some "cloud" based thing, where MS, or NSA or whoever may listen as at
will...
Karl
D.J.W. van Kooten
Dec 17, 2013, 12:14:48 PM12/17/13
to
On Mon, 16 Dec 2013 23:19:09 +0100, Karl Faller
<mail_withoutthat_@_drei-f_andthat_.de> wrote:
Hello Karl,
>Even if these hypothetical funcs were marked as depreciated, IMO it is
>not correct to "kill" them without any notice.
Fully agreed but we're not yet sure if this is the case. Suppose the
programs having problems, like VO, did not use the FTP access "by the
book". Could be the case...
full of tricks to keep your PC in a local account instead of a
Microsoft account and prevent that searching in the 8.1 Start screen
adds Bing search keywords, preferably personalized based on your
"Windows 8.1 experience".
Well, I can only conclude that as long as you're logged in with your
Microsoft account, all kind of data are collected and sent to
Microsoft. Certainly things you search (most people only want to
search on their private data on their PC and do not realize that these
searches are collected too) but likely also other things you do.
If I want to post an issue to e.g. Advantage Database Developers
forum, I can nearly only login with a couple of external services (or
ask 1 time access codes per mail for every time I login). As soon as
I've posted the question, I close my browsers because I noticed that
even when I have unchecked "Remain logged in" Google and I logged out
from the ADS forum, opening gmail directly dircets me to my mails. I
have nothing important there but I am sure that as long as I am logged
in, Google tries to collect everything it can from my PC.
For Windows 8.1 once I update I will use a local account like I did
for 8.0. It can sometimes be handy to have access to a Skydrive from
Explorer, and I will have to find a way to do that with 1 click
(+login) and disconnect again with 1 click. Now it requires lots of
clicks, twice a login and I can guess why this is made so difficult.
Dick
<mail_withoutthat_@_drei-f_andthat_.de> wrote:
Hello Karl,
>Even if these hypothetical funcs were marked as depreciated, IMO it is
>not correct to "kill" them without any notice.
programs having problems, like VO, did not use the FTP access "by the
book". Could be the case...
>
>maybe i'm getting paranoid, but can't help to think, that again a
>established way of communication gets killed to urge people to use
>some "cloud" based thing, where MS, or NSA or whoever may listen as at
>will...
>
Agreed too. If you installl Windows 8.1, you must really perform a bag
>maybe i'm getting paranoid, but can't help to think, that again a
>established way of communication gets killed to urge people to use
>some "cloud" based thing, where MS, or NSA or whoever may listen as at
>will...
>
full of tricks to keep your PC in a local account instead of a
Microsoft account and prevent that searching in the 8.1 Start screen
adds Bing search keywords, preferably personalized based on your
"Windows 8.1 experience".
Well, I can only conclude that as long as you're logged in with your
Microsoft account, all kind of data are collected and sent to
Microsoft. Certainly things you search (most people only want to
search on their private data on their PC and do not realize that these
searches are collected too) but likely also other things you do.
If I want to post an issue to e.g. Advantage Database Developers
forum, I can nearly only login with a couple of external services (or
ask 1 time access codes per mail for every time I login). As soon as
I've posted the question, I close my browsers because I noticed that
even when I have unchecked "Remain logged in" Google and I logged out
from the ADS forum, opening gmail directly dircets me to my mails. I
have nothing important there but I am sure that as long as I am logged
in, Google tries to collect everything it can from my PC.
For Windows 8.1 once I update I will use a local account like I did
for 8.0. It can sometimes be handy to have access to a Skydrive from
Explorer, and I will have to find a way to do that with 1 click
(+login) and disconnect again with 1 click. Now it requires lots of
clicks, twice a login and I can guess why this is made so difficult.
Dick
0 new messages