[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Hamm frozen, Slink created



On 3 Apr 1998, Kai Henningsen wrote:

> dwarf@polaris.net (Dale Scheetz)  wrote on 02.04.98 in <Pine.LNX.3.96.980402193429.2360A-100000@dwarf.polaris.net>:
> 
> > On Thu, 2 Apr 1998, Brian White wrote:
> >
> > > > > I wonder, have you ever considered using hardlinks? It seems to me
> > > > > that would eliminate a lot of problems people have mirroring things
> > > > > (if mirror programs handle them correctly), and simplify your work
> > > > > too.
> > > >
> > > > Hard links would specially help with the msdos directory, as several
> > > > dos/windows ftp clients don't follow symlinks and the user ends up with
> > > > a bunch of zero length files.
> > >
> > > <puzzled look>  That seems odd.  Wouldn't be the ftp server that deals
> > > with following the symlinks to the correct file?  Or does the ftp client
> > > read the size out of the "dir" and only allow that many bytes?
> >
> > It is the ftp client which decides (if it has the brains) to take
> > advantage of the servers ability to follow symlinks (mc has a radio button
> > for "follow symlinks" in its copy dialog that works via the ftp file
> > system in the desired way)
> 
> That seems quite nonsensical. There's *no* way to "not follow" a symlink;  
> if you get or cd a symlink, following it is what will happen.

This is simply not true. Mount a Debian Official CD on a dos machine; use
Norton Commander and go to the msdos-i386 directory on the disk; select
some files and copy them somewhere on the hard disk; the result is a bunch
of zero length files.

The same exact thing occurs with some DOS and Windows FTP clients.

> 
> I believe what happens is that some FTP clients try to parse ls -l output,  
> and don't understand what ls gives for symlinks, and thus do broken things  
> with the result.
> 
> > DOS hasn't the faintest inkling of what a symlink is. As a result several
> > trumpet-winsock clients don't do the right thing, resulting in an archive
> > of zero length files.
> 
> No, that can't be the reason. If you simply follow the RFC, there's no  
> reason why you should know anything about symlinks for them to work.
> 
While I don't agree. The issue is irrelevent. For whatever reason, some
DOS ftp clients are broken when it comes to symlinks.


> The problem lies with software that tries to make the protocol do what  
> wasn't designed into it. Mirror is such a software; usually you go parsing  
> ls -l output. That output is, of course, not standardized; look how many  
> different formats mirror understands, yet there are always new ones. Those  
> Windows clients obviously usually only understand "typical Unix" ls -l  
> without symlinks.
> 
> The right solution to this is the FTP MLST extension that's currently in  
> the works (I mentioned it a few days ago in the mirror discussion). That  
> one allows you to find out even more about files than ls -l, and it does  
> so in a portable way. Hopefully, it will actually get used.
> 
This will do nothing for existing broken software (which could have been
built to work correctly in the first place, but wasn't).

Luck,

Dwarf
--
_-_-_-_-_-   Author of "The Debian Linux User's Guide"  _-_-_-_-_-_-

aka   Dale Scheetz                   Phone:   1 (850) 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, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org


Reply to: