🚀 go-pugleaf

In article <1991Jun27.180424.3522@alias.com> chk@alias.com (C. Harald Koch) writes:
> Except you have the problem that many OSes use a different separator
> character than /,

That doesn't affect the format. A / in the format doesn't mean you send
/ to the remote ftp server; it means you cd to the thing before the /.
See my response to Ed's examples of what the directory-file format can't
handle.

> and allow slashes in file names (most commonly used for
> putting dates in filenames...).

That does affect the format, but the quoting rules I defined handle it.
ftp.foo.com:"this is a filename with /s and 's"' and "s'/bar.

> Then there are OSes that don't have 'directories', they have 'disk packs',
> and then there are the hybrids (e.g. VMS). Every designer seems to want to
> create yet another incompatible syntax for filesystems...

If you can't do it with cd this, cd that, cd the other thing, and then
get the file, then you simply cannot get the file via ftp. The format as
I've defined it lets you cd this, cd that, cd the other thing, and then
get the file, and you can put arbitrary characters anywhere. It works
for VMS. It works for TOPS-20. It works for MS-DOS. It even works for
VM/CMS, not that I've seen any IBM anonymous ftp sites.

> The clearest way to handle all the different variations out there is to keep
> directory and file information separate.

Uh, no. That *cannot* handle certain files which rcp format (with the
multiple cd semantics) can, and I fail to see why you consider it
``cleaner'' than what's obviously a more general and more accurate
representation of reality.

> Remember, all the world's not UNIX.

That's what I've been trying to say. Trying to force everything into
a one-cd, one-get model is a UNIX-centric view that we should not impose
on a general archive format.

Ed, what do you think?

---Dan