What am I doing wrong?

c:\temp>ftp

ftp> open empeg

Connected to empeg.

220 Connected.

User (empeg:(none)):

230 Login okay.

ftp> cd proc

250 "/proc" directory changed

ftp> ls

200 Okay.

150 Opening data connection.

empeg_power

empeg_therm

empeg_id

empeg_rds

empeg_state

empeg_usb

empeg_ir

empeg_cs4231

audio

empeg_notify

empeg_screen.png

empeg_screen.raw

misc

slabinfo

swaps

mounts

locks

cmdline

ioports

dma

filesystems

interrupts

partitions

devices

stat

kcore

self

cpuinfo

version

kmsg

meminfo

uptime

loadavg

226 Okay.

ftp: 328 bytes received in 0.01Seconds 32.80Kbytes/sec.

ftp> cd empeg_kernel

431 No such directory.

ftp>

Don't try to cd to empeg_kernel -- it's a "file", not a "directory".

Just overwrite it with the new kernel.

Cheers

I'll make that clearer in the FAQ. That's just something i stuck in there to make a full entry out of later... which i'll do.... now.

Yes, that was it, thanks.

Loren. Update that in the FAQ. Here is what I had to do:

- Rename my "v221.hijack.v200b11.mk2.zImage" file to "empeg_kernel" on the PC's hard disk.

- Surf to "/proc" on the player and upload the file "empeg_kernel" to the player.

- Pause and unpause the player a couple of times to make the file "take" (still don't know why this happens)

- Reboot the player.

Then the new kernel was in place.

So the instructions in the FAQ to "surf to /proc/empeg_kernel" are incorrect. You do not surf to "/proc/empeg_kernel", you surf to "/proc" and upload a FILE called "empeg_kernel".

Is the advantage to this that you can do a kernal upgrade with a network connection?

Yes. Also, it is faster than serial.

how's that?

By the way, I've never been clear on why ``ls'' often doesn't return complete listings and ``dir'' does. Not just in Hijack, either. Anyone know right off the bat?

>Once you've got Hijack installed, it will allow you to update the
>kernel via ethernet, which is much faster than flashing via serial
>connection.

Change that wording to say:

Once you've got Hijack installed, it will allow you to perform

future kernel updates via ethernet, which is much faster than

flashing via the serial connection.

Thanks

how's that?

Fine, except for empeg_kernel doesn't even show up as a file in my graphical FTP client. I just upload the file named empeg_kernel and it works.

That's a bug in your client. But when you do the upload, it really does try to "overwrite" /proc/empeg_kernel.

Cheers

done

The differences (if any) between FTP ls and FTP dir are on the client side, not the server. Hijack always returns detailed listings. The Linux CLI FTP client I use here does exactly the same with dir as with ls.

Some clients want you to do "ls -l" for details.

-ml

argh, i had a whole thing typed about that from an old thread... but couldn't confirm it enough to be sure. Are you using CuteFTP?

edit: See this thread.

Looks like some FTP clients have an option to hide system files and the like. Have you checked for that in your options Tony?

So it takes say.... 1 second instead of 2?

Hmmm. Well let me tell you what I see and you tell me why. The Windows CLI FTP client sends ``LIST'' for ``dir'' and ``NLST'' for ``ls''. ``ls'' doesn't show a lot of stuff in /proc, including empeg_kernel. ``dir'' shows it all.

Okay, that's just your client software then. NLST means "Names only LiSTing.

-ml

Right. But it should still show all the files in that directory, which it doesn't, and despite the fact that I put very little faith in Microsoft, I find it hard to believe that they would arbitrarily filter out random data from the directory listing, expecially since they pretty much just stole the client from the BSD source.

In reply to:

---

RFC 959
NAME LIST (NLST)

This command causes a directory listing to be sent from
server to user site. The pathname should specify a
directory or other system-specific file group descriptor; a
null argument implies the current directory. The server
will return a stream of names of files and no other
information. The data will be transferred in ASCII or
EBCDIC type over the data connection as valid pathname
strings separated by CRLF or NL. (Again the user must
ensure that the TYPE is correct.) This command is intended
to return information that can be used by a program to
further process the files automatically. For example, in
the implementation of a "multiple get" function.

---

Technically speaking, /proc/empeg_kernel is a device, not a file (even though it looks like one, as do all *nix devices), and as such is not normally a desirable item for NLST to show.

Hijack kftpd just returns files and symlinks in response to NLST, not devices, and not directories.

Cheers

From the same RFC:

In reply to:

---

LIST (LIST)

This command causes a list to be sent from the server to the
passive DTP. If the pathname specifies a directory or other
group of files, the server should transfer a list of files
in the specified directory. If the pathname specifies a
file then the server should send current information on the
file. A null argument implies the user's current working or
default directory. The data transfer is over the data
connection in type ASCII or type EBCDIC. (The user must
ensure that the TYPE is appropriately ASCII or EBCDIC).
Since the information on a file may vary widely from system
to system, this information may be hard to use automatically
in a program, but may be quite useful to a human user.

---

So shouldn't LIST not return empeg_kernel either?

No, LIST should show everything, including subdirectories.

NLST is intended (as the RFC says) for use with MPUT/MGET, which really just want files, so that's what they get.

Cheers

So it takes say.... 1 second instead of 2?

More like 5 seconds instead of 1.5 or 2 minutes...

That makes sense. Thanks. Too bad there aren't standard best-practices documents lying around for this.