The debian-private mailing list leak, part 1. Volunteers have complained about Blackmail. Lynchings. Character assassination. Defamation. Cyberbullying. Volunteers who gave many years of their lives are picked out at random for cruel social experiments. The former DPL's girlfriend Molly de Blanc is given volunteers to experiment on for her crazy talks. These volunteers never consented to be used like lab rats. We don't either. debian-private can no longer be a safe space for the cabal. Let these monsters have nowhere to hide. Volunteers are not disposable. We stand with the victims.
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: msdos-i386 directory...

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.

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,  
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 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.


MfG Kai


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