Subject: Re: Missing files and truncation.
From: Andrew B. Arthur (arthur99@global2000.net)
Date: Wed Aug 04 1999 - 09:34:19 MDT
> Thus spake Spino (spino@apc.net):
>> But also, I'm noting a problem..some Files of YDL are being truncated as
>> they dl to the Mac Hard Drive. Are ther eany solution to this truncation
>> so one may install properly?
If your FTP client isn't Anarchie Pro, you should have no problem with
truncated file names--RPM supports them as far as I know, it gets it's info
from the beginning of file names then checks them against the spec file.
The problem with Anarchie Pro is that it has a rather alternative way of
dealing with two files with the same name (or long file names), it names
them like this: kde-net-cvs-sna#1.rpm, kde-net-cvs-sna#1.rpm. And with names
like that, it gives Linux a fit.
Other Mac FTP clients don't have problems like that... the same RPM
downloaded in other clients becomes named something like
kde-net-cvs-snap-2.0.ppc.r or something like that. Note that format doesn't
have weird chars in it, nor does it mess with the first part of the name.
Also, don't forget to be transferring all of them as binary and not text --
most Macintosh systems default to transferring .rpm files as text, thinking
they are real player media files.
> No, the Mac filesystem cannot handle filenames > 32 chars[***], so you have to
> download to a non-Mac file system and do an install from there.
See above.
> [***] Actually, HFS+ can handle pretty much any filename size [and in Unicode,
> too], but the current MacOS API has no way to handle anything bigger than 32
> chars.
The Mac OS pre-X File Manger APIs are kind of dated and are still mostly
written in m68k assembly, so they don't have particularly great speed on the
PowerPC.
HFS+ is a wonderful format, it supports every feature in Ext2fs, including
never fragmented, long file names, Unicode, full permissions system, quotas,
and is really, really fast to name a few. It's a great system. It's really
to bad that Apple's current implementation is just a sucky emulation of HFS
standard when mounting HFS+ disk. This emulation also kills performance,
since it's quite unefficient to be re-mapping APIs.
> Take a look at FSSpec and you'll see why. *sigh.
I'll second that. HFS+ rocks, but all current support for it bites. When Mac
OS X Consumer + Linux fully supports it, it should be a great system. Of
course, it does seem as if Apple is kind of moving away from HFS+ for now,
having more interest in *bsd's own UFS. And yes, Linux supports UFS right
now.
> not sure if this is fixed in Mac OS X;
It is because, Apple has finally rewritten the file manger in Mac OS X (at
least consumer) for the first time in a decade and 3 years (last time it was
completely re-written was winter? of 1986 with support for HFS and A/UX
partitioning scheme)..
Thanks,
Andrew Arthur a.k.a. AArthur
arthur99@global2000.net
AIM: arthur998
This archive was generated by hypermail 2a24 : Sun Sep 05 1999 - 13:46:32 MDT