Re: Bochs - Free PC emulator
Re: Bochs - Free PC emulator
- Subject: Re: Bochs - Free PC emulator
- From: Charles Srstka <email@hidden>
- Date: Sun, 6 Oct 2002 02:19:32 -0500
On Saturday, October 5, 2002, at 09:59 PM, Angela Brett wrote:
I don't know much about which alternative preserves which metadata but
here's my take on it...
I do: Disk images *always* preserve *all* metadata. The .dmg format is
the only compression format that you can count on to do so.
It's not particularly relevant, but probably most of what I get from
the internet is email and web pages, which of course are not packaged
in any special way. I'd say 90% of my downloads of large files are
applications. Other people download a lot of mp3s, movies etc and
again they're not packaged in any special way... the main thing I know
of which is distributed in a disk image or archive of some kind is
software.
Exactly.
Hmm... I haven't noticed it doing that any more than Disk Copy does...
but perhaps I'm just not very observant, or I switch another app back
to the foreground immediately anyway.
Hmm, you're right, Disk Copy is doing that as well. I guess it's not as
noticeable because Disk Copy is simply mounting the image, which takes
less time because it is not decompressing the entire archive at this
point.
I don't see what that has to do with disk images versus other
archives... all methods (well, apart from Installer packages I
suppose) let the user drag and drop the file wherever they want. The
difference with disk images is than instead of simply moving the file,
they have to copy it, which does take a while. Not as long as it takes
to download the file to start with, but long enough to be annoying
sometimes, as it slows down anything else which is using the disk. I
know the file is on my hard disk already, and yet I need to copy it.
It's fine to have installers on disk images, because then I'm just
running the installer from the image which would have to copy files
either way. I would have deleted the installer anyway so the extra
step of putting the .dmg file in the trash is not such a hassle. But
copying a plain ol' application file from one place on my disk to
another seems wasteful and slow.
But copying the files is precisely what you're doing when you
decompress a StuffIt archive, when you think about it. Actually, with
StuffIt, you could end up copying the file twice if you want to put the
file on a different partition than the one the archive downloaded and
decompressed to. And then there'd be another garbage file to delete...
with a disk image, you simply drag it right to where you want it, and
it decompresses straight to there. Simple as that.
I thought that too when I first read the comment. But yesterday I was
reminded... I put a disk image in the trash and now when I try to
empty the trash I got an error (-8062.) That's happened in the past
with a disk image - I have to log out before I can empty the trash.
Well, perhaps I could remove it using the command line, but I'm a Mac
user, damnit, and I use the GUI! :)
Sounds like a Finder bug, not a Disk Copy bug, to me. That could have
been any file that had been open at some point that the Finder refused
to delete. I've put apps in the Trash, and had the Finder refuse to
delete the icon file for some bizarre reason... the Finder is still a
bit buggy.
Hey, I happen to think that deleting the archive afterwards is a good
thing, I wish .dmgs would be deleted automatically. I've never seen
Expander delete the archive when the extraction fails... maybe I don't
have the latest version. Anyway, I'm not particularly advocating
Stuffit (I have seen it fail to open archives before, and indeed it
does chop the ends off long file names), just pointing out why I don't
particularly like disk images.
Deleting the archive is a terrible feature, if the archive was 30 MB
and you either cancelled the decompression or it encountered some
error. Or if the thing actually completed decompressing a .tar.gz, but
chopped all the filenames short, and deleted the archive so you
couldn't decompress it with some unarchiver that actually worked.
Well, that's the beauty of hierarchical file systems actually. Just
like drag'n'drop, the ability to browse something just like folders
after it's been decompressed/mounted/whatever has nothing to do with
how it was packaged. (Unless it's an installer package of course.)
But to browse something *before* it is decompressed, you cannot beat
the elegance of a disk image. And there is no form of archive where you
can actually *run* the app straight from the archive file to see if you
want the software before even decompressing it to the hard disk!
I don't think either of these things are particularly relevant. The
average user (at least, the average user who comes from Mac OS rather
than from NeXTStep/BSD/Linux or whatever) uses the GUI, especially for
simple things like opening files downloaded from the internet.
Sure, if web browsers automatically used hdiutil to mount disk images,
it'd be okay. (Well, maybe not actually... it might somewhat confuse
the novice who doesn't realise they have to drag the file somewhere
before going offline... but then I suppose it's just like an iDisk and
we're all supposed to be able to use those.) But they don't. So
hdiutil is only useful to people who know how to use the command line
and hdiutil, and can be bothered copying a URL, switching to a
terminal and typing in a command rather than clicking on a link.
I'm convinced that this is in store for us in the future. For the
present, I think someone (Mike Bombich maybe?) has put together an
AppleScript Studio wrapper around hdiutil, so you can do it with the
GUI. You should try it sometime - it's really handy and leaves
absolutely no garbage files behind.
However, when this feature becomes standard with Mac OS X browsers, it
won't be any good if developers are packaging their files via .sit or
some other screwy format. For this to be a benefit, programmers need to
distribute their files in .dmg format *today*.
As for confusing users, in my experience nothing confuses them more
than having to trash the garbage files. "You mean after all that time
we waited for it to download, now we're just going to throw it away?!"
Again, that's how you install files no matter whether they were in a
disk image, StuffIt archive, or some other kind of archive (except
Installer packages, which are a different issue entirely, they're used
when files have to be put into specific places or whatever.) It's part
of the Mac OS X metaphor, and is not going to go away, no matter how
the files were archived to begin with.
You might respond that with a StuffIt archive you have to doubleclick
the file to decompress it first, but you also have to doubleclick disk
images to mount them first. Both tasks are usually handled
automatically by web browsers anyway so it's not an issue.
With disk images, you drag the file directly from the archive to the
destination on the hard disk. No middle man. And if the disk image was
mounted remotely over the network, no garbage files to clean up.
Yeah. Anyone want a nice cup of cocoa* with a chocolate fish in it?
The marshmallow and chocolate melt really nicely. :)
* I'd call it hot chocolate, but I've heard Americans call it cocoa
and that seemed more fitting for this list.
Well, as an American myself, I've actually heard it called hot
chocolate more often than cocoa, but it's all good. :-)
Charles
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.