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"
>