Re: Error: "not a plain file"
Ted Keller <[email protected]> Tue, 16 Jan 2007 22:57:22 -0500 (EST)
| Newsgroups | gmane.network.ftp.wuftpd.user |
|---|---|
| Message-ID | <[email protected]> |
I usually see this error if I'm trying to put or get a directory (not a plain file). This leads me to believe the file - one end or the other - is pointing to something other than a file. Now - my only suspicions as to why it works the second time is that during investigation, the client - or the server has changed directories...? ted keller On Tue, 16 Jan 2007, Bob Luckin wrote: > I'm surprised that the server would be executing code to check the file type > of a file it is writing (it does do this when asked to get a file, though). > You might want to turn on the command logging in the server and see just what > it is being requested to do by the client when this error occurs. If you > don't see any of the commands which would cause the server to check the file > type (from a quick look at the source, I think those would be the RETR, MDTM, > SIZE and SITE CHECKSUM commands), then perhaps it's coming from the client. > If it _is_ coming from the server, then the knowing which command is causing > it may help you zero in on the problem. > > Good luck ! > > Cheers, Bob > > On Tue, Jan 16, 2007 at 07:44:59AM -0800, Gregory Hicks wrote: > > Greetings: > > > > I've looked and looked... Found lots of source code examples of this > > message and even a few questions like this - but no answers. > > > > I have a client that is trying to upload a <file>.tar.gz to a wu-ftpd > > FTP server. The local ftp client (dunno what it is just yet) is > > showing this error: > > > > > > > > Using binary mode to transfer files. > > > > > > ftp> bin > > > > > > 200 Type set to I. > > > > > > ftp> cd from_cust > > > > > > 250 CWD command successful. > > > > > > ftp> put to_ae_0112.tar.gz > > > > > > local: to_ae_0112.tar.gz remote: to_ae_0112.tar.gz > > > > > > to_ae_0112.tar.gz: not a plain file. > > > > I'm not sure if this particular error is from the client or server. (I > > think from the server) but the funny thing is that if we try this exact > > sequence a second time in the same session, the transfer succeeds. > > > > The really puzzeling thing is that in my years of administering this > > particular server, I have never seen this error before. > > > > Any thoughts on what might be causing this? And how to fix? > > > > Assist will be appreciated. > > > > Regards, > > GRegory Hicks > > > > --------------------------------------------------------------------- > > Gregory Hicks | Principal Systems Engineer > > Cadence Design Systems | Direct: 408.576.3609 > > 555 River Oaks Pkwy M/S 9B1 > > San Jose, CA 95134 > > > > I am perfectly capable of learning from my mistakes. I will surely > > learn a great deal today. > > > > "A democracy is a sheep and two wolves deciding on what to have for > > lunch. Freedom is a well armed sheep contesting the results of the > > decision." - Benjamin Franklin > > > > "The best we can hope for concerning the people at large is that they > > be properly armed." --Alexander Hamilton > > -- > Bob Luckin [email protected] "Coder, adapt; FTP Ada, redo C" >