Re: msdos-i386 directory...

[Dale Scheetz <dwarf@polaris.net>]

On 29 May 1997, Kai Henningsen wrote:

> dwarf@polaris.net (Dale Scheetz)  wrote on 29.05.97 in <Pine.LNX.3.95.970529133059.2616B-100000@dwarf.polaris.net>:
> 
> > using Trumpet Winsock from windows tell me that they could not get the
> > files from my site that were symbolic links, they only got the link. If
> > this is a problem at my end, I need to understand what to do. My
> > impression is that many DOS/Windows ftp clients don't have the facility of
> > following links. I haven't had an opportunity to test these issues, since
> > doing so would require setting up a machine and an account, neither of
> > which do I have resources for at the moment.
> 
> That doesn't make much sense - it's the server, not the client, that has  
> to follow that link. In fact, the server should not even be *able* to give  
> out the "pure" link.

Well, my experience with dos and symlinks is minimal. I have only been
reporting second hand information given me by other dos users.
However, I have experience in Linux with this issue and what you say above
does not follow my experiences. For instance, I use mc and its virtual ftp
file system to download the msdos-i386 directory. Its default is to
download the links, not the files pointed to. There is an option on the
copy dialogue box to follow symlinks but it is not the default.
While I agree that the server must be able to provide the "right thing" it
seems to me that the client program is in control of what gets served.
Since dos doesn't know about links, I suspect that many dos programs
simply ignore their existance, yielding the erratic results we see
reported.

> 
> My guess - as I wrote in a parallel message - is that the ftp client tries  
> to be clever, and shoots itself in the foot. If I were a betting person,  

Dos programs don't ever need to be clever, which is normaly lucky since
DOS doesn't support cleverness ;-)

> I'd bet high odds that this is a bug in the client - and still good odds  
> that it's either only a single client, or all of those come from a common  
> code base.
> 
> And all of them are probably visual ftp clients. I can't imagine a command  
> line client getting that wrong.
> 
> Please, find a concrete scenario that goes wrong (which exact ftp client -  
> version, please - and which ftp server). We should find out what's really  
> going on, here, before this gets us bad publicity.
> 
I don't think that there is a concrete scenario. The fact that I have only
recently noticed the flaw, comes from my recent work at organizing the
testing group. During "testing" I have had the chance to try things that I
didn't need personaly, or that were too dangerous to "try out" on my
development system. As a result I have gotten comfortable with dselect
(something I never thought would happen) and discovered several hidden
corners with their dark little secrets ;-)
I think, the fact that we haven't gotten any bad press on this comes from
the fact that it really doesn't impact many people, since we advertise the
floppy installation method (which can be downloaded to dos with none of
these problems) and once you have a base system there is no reason to
return to dos.
The potential problem in the future comes from the fact that the dos
environment is rapidly becoming our target market (this is a much larger
market than either Slackware or RedHat). 
I think our goal should be to make it work in "every" case, even though
that is obviously not an attainable goal.

> > > I wrote a (currently messy) patch to mkisofs that allows complex
> > > transformations to be performed on the unix names before they get written
> > > to the CD as 8.3 names.
> > >
> > > With a bit of luck, this should allow a CD to be produced that contains
> > > for example:
> > >
> > >   bo/binary-i386/admin/pcmcia-modules-2.0.29_2.9.5-2.deb
> > >
> > > when mounted using RockRidge, but under DOS shows the same file as:
> > >
> > >   STABLE/BINARY/ADMIN/PCMMD229.DEB
> > >
> > > not because it is linked, but because that is the real iso9660 name that
> > > RockRidge allows us to see in the longer form.
> > >
> > > Would this fix your problem ?
> > >
> > As I understand it, DOS doesn't understand RockRidge. I build my CDs with
> > -R. If DOS understood this then it would already have the kludged up
> > RockRidge 8.3 file names available.
> > So, I think the answer is: "No, it will not help.".
> 
> Bad guess. This is supposed to work _because_ DOS doesn't understand  
> Rockridge; if it did, it would see the long name.
> 
> And yes, this would most certainly solve the problem for CDs.
> 
Well, the simpler solution is to turn the symbolic links into hard links.
Thanks to a one line perl program from Guy I can do this easily, and will
be providing such links on my Gold CDs. This probably doesn't work for the
archive though.

Thanks all,

Dwarf
-- 
_-_-_-_-_-_-                                          _-_-_-_-_-_-_-

aka   Dale Scheetz                   Phone:   1 (904) 656-9769
      Flexible Software              11000 McCrackin Road
      e-mail:  dwarf@polaris.net     Tallahassee, FL  32308

_-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_-


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-private-request@lists.debian.org . 
Trouble?  e-mail to templin@bucknell.edu .