[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: FTP_delete
Hi Scott and all list-members.
I agree and understand the conversion of user type ftp command into
acceptable ftp server commands. Thanks for the fine explanation.
I have done are more detailed research on what's going on and here
is the result:
I am in debug mode for the programs in question:
it has build a table with file name from the dir at server side:
if ftp_list(ftp: '' : 1000 : %addr(Files):FilesFound)
now looping thru the table and processing
if ftp_get(ftp: Files(X)) < 0;
wwMsg = 'Error FTP-server get file: ' + ftp_errorMsg(0);
FILES(X) =
....5...10...15...20...25...30...35...40...45...50...55...60
1 'sched_20080409083435.txt '
61 ' '
121 ' '
181 ' '
241 ' '
I have verified the Files(x) is padded with x'40'.
The file is retrieved and processed.
After processing, and while in debug mode I could give
an additional delay, the next ftp command is:
if ftp_delete(ftp: Files(X)) < 0;
wwMsg = 'Error FTP-server delete file: ' + ftp_errorMsg(0);
FILES(X) =
....5...10...15...20...25...30...35...40...45...50...55...60
1 'sched_20080409083435.txt '
61 ' '
121 ' '
181 ' '
241 ' '
Files(X):x
00000 A2838885 846DF2F0 F0F8F0F4 F0F9F0F8 - sched_2008040908
00010 F3F4F3F5 4BA3A7A3 40404040 40404040 - 3435.txt
00020 40404040 40404040 40404040 40404040 -
00030 40404040 40404040 40404040 40404040 -
00040 40404040 40404040 40404040 40404040 -
00050 40404040 40404040 40404040 40404040 -
00060 40404040 40404040 40404040 40404040 -
00070 40404040 40404040 40404040 40404040 -
00080 40404040 40404040 40404040 40404040 -
00090 40404040 40404040 40404040 40404040 -
000A0 40404040 40404040 40404040 40404040 -
000B0 40404040 40404040 40404040 40404040 -
000C0 40404040 40404040 40404040 40404040 -
000D0 40404040 40404040 40404040 40404040 -
000E0 40404040 40404040 40404040 40404040 -
000F0 40404040 40404040 40404040 40404040 -
resulting in:
Error FTP-server delete file: sched_20080409083435.txt not deleted.
Doing this with extra delay for about 2 mins. before the Ftp_delete
should ensure there is no timing problem here.
The joblog is:
[1]> RETR sched_20080409083435.txt
150 Opening ASCII mode data connection for
/Download/Schedule/sched_20080409083435.txt.'
[2] 226 Transfer complete.
> DELE sched_20080409083435.txt
[3] 500 sched_20080409083435.txt not deleted.
[1] Message ID . . . . . . : CPF9897
Date sent . . . . . . : 06.05.08 Time sent . . . . . . :
21:49:56
Message . . . . : 4: > RETR sched_20080409083435.txt
[2] Message ID . . . . . . : CPF9897
Date sent . . . . . . : 06.05.08 Time sent . . . . . . :
21:49:57
Message . . . . : 4: 226 Transfer complete.
[3] Message ID . . . . . . : CPF9897
Date sent . . . . . . : 06.05.08 Time sent . . . . . . :
21:51:52
Message . . . . : 4: 500 sched_20080409083435.txt not deleted.
Can this help getting closer identifying the source of the problem ?
Brgds
Helge
-----Original Message-----
From: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx
[mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx]On Behalf Of Scott Klement
Sent: Tuesday, May 06, 2008 7:23 PM
To: HTTPAPI and FTPAPI Projects
Subject: Re: FTP_delete
Hi Helge,
First, let's make the distinction between what you type (which is you,
as the user, telling the FTP client what you want to do) and the command
that's sent to the server (which is the FTP client telling the server
what to do).
Whether you've typed 'del' or 'dele' or 'delete' or 'remove' or 'erase'
doesn't matter. In a GUI client, you might right-click the file and
choose a 'delete' option and not type anything at all! How you tell the
client what you want to do doesn't matter. Whether you've typed 'del'
or 'dele' doesn't matter.
What's important is what the FTP client sends to the server! The FTP
client *must* send 'DELE <filename>' to the server. It *must* be that
exact phrase. And that's what FTPAPI is sending, and it's also what the
i5/OS FTP client is sending... I see no difference. And as long as they
are sending the exact same thing, the server MUST respond with the same
thing.
However, I have a new thought... I said I *see* no difference. What if
there's something I can't see? FTPAPI automatically trims trailing
blanks from the end of the string, but perhaps there's some other
non-printable character in the string? Could you check for that?
I've already suggested that it might be a timing issue because you're
doing the RETR immediately before the DELE. Have you explored that, at all?
Helge Bichel wrote:
> Dear Scott.
>
> I am aware of the 500 is coming from the server, and sure the 'dele' in
> FTPAPI
> is the correct command for deleting files on server side.
>
> Now your suggested test with the i5 Ftp client, here is the log
> Windows_NT Windows Server 2003 Standard Edition (Build 3790) Service
Pack
> 1
> debug 1
> DEBUG is on. DEBUG value is 1.
> cd download
> >>> CWD download
> 250 CWD command successful.
> cd schedule
> >>> CWD schedule
> 250 CWD command successful.
> del sched_20080314140242.txt
> >>> DELE sched_20080314140242.txt
> 200 sched_20080314140242.txt deleted.
> dele sched_20080314140345.txt
> >>> DELE sched_20080314140345.txt
> 200 sched_20080314140345.txt deleted.
>
> I deleted 2 files with 'del' and 'dele'.
> On the FTP server side the files are actually deleted.
-----------------------------------------------------------------------
This is the FTPAPI mailing list. To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------
-----------------------------------------------------------------------
This is the FTPAPI mailing list. To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------