Error: "not a plain file"

Discussion:

Gregory Hicks

2007-01-16 15:44:59 UTC

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

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

2007-01-16 19:49:27 UTC

Permalink

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

Post by Gregory Hicks
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

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 ***@ti.com "Coder, adapt; FTP Ada, redo C"

Ted Keller

2007-01-17 03:57:22 UTC

Permalink

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

Post by Bob Luckin
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

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