[delphizip] Re: New format
- From: "Russell Peters" <russellpeters@xxxxxxxxxxx>
- To: <delphizip@xxxxxxxxxxxxx>
- Date: Sat, 2 Nov 2002 08:05:47 +1100
Actually I doubt thet there is a 'standard' for any filenames - they are
just stored as a series of bytes about the only 'direction' is that
backslashes be stored as slashes!
Unicode is not as difficult as MBCS (WinXP/NT), to work with them you must
know code page they were 'encoded' with!
- Russell Peters
----- Original Message -----
From: "James Turner" <james.d.h.turner@xxxxxxxxxxxx>
To: <delphizip@xxxxxxxxxxxxx>
Sent: Friday, November 01, 2002 12:42 PM
Subject: [delphizip] Re: New format
>
> Gerard,
>
> You may very well be right in your analysis that the Zip format is less
than
> ideal for your requirements, however, I would certainly not be confident
in
> actually agreeing with you unless I knew exactly what you want to do. In
any
> case, there are several archive formats around these days so it may be the
> case that one of these would serve your requirements better. I am new to
> this field and know nothing of the likes of RAR archives but if you
explain
> in detail exactly what you want to do, someone on this list may well be
able
> to point you in the right direction.
>
> So far as designing a new format is concerned, I would suggest you sit
down
> with a pencil and paper for a couple of hours or so and scribble down your
> thoughts and the necesary algorythms for manipulations such as rename. I
may
> be totally wrong, but I suspect that there are only two significant
changes
> that might be useful.
> 1 : Strip variable length data from the file header blocks (or eliminate
> them altogether). This would permit easier renaming.
> 2 : Create some sort of allocation unit system (rather like disc sectors
> but variable length). This may permit faster delete and overwrite
operations
> but has major drawbacks with regard to overall compression efficiency.
>
> In other words, perhaps you are being unrealistic with regard to what you
> want. However, there are certainly subscribers to this group who know
vastly
> more about this stuff than I do.
>
> Personally, other than the fact that zip headers and records use 32bit
> integers instead of 64bit ones and there is no standard method of using
> unicode filenames, I think the zip format is ok. However, large archives
are
> undoubtedly troublesome if high speed manipulations are required.
>
> Perhaps what you need is a virtual compressed disk system like
> DriveSpace/DoubleSpace. I seem to recall that you could only allocate a
> fixed amount of disk space for such virtual disks but I could be mistaken
or
> someone may have designed a system that eliminates this restriction. Of
> course, development in this area has pretty much stopped because hard
disks
> have such huge capacities these days. Perhaps also, the DBX file format
> (used by Outlook Express amongst other programs) might be right for you
but
> I have no knowledge in this area.
>
> Sorry if my thoughts on this subject are not very helpful.
>
> James Turner
>
> PS
> My website will be going live in a day or so. After that I had planned to
> start work designing my own minimalist zip implementation. However, as
Eric
> has just pointed out, there is a Nanozip to consider. I've only glanced at
> this so far but it looks like it is well written and it may cover all my
own
> requirements for a pure Delphi zip solution. In which case I shan't bother
> writing my own version.
>
> ----- Original Message -----
> From: "Gerard" <gslurink@xxxxxx>
> To: <delphizip@xxxxxxxxxxxxx>
> Sent: Thursday, October 31, 2002 10:32 PM
> Subject: [delphizip] New format
>
>
> >
> > Hi all,
> >
> > I am using now delphizip for several months and I am having difficulties
> > all the time achieving the things I have in mind. I mostly manage but it
> > takes quite some tricks to get it done. I don't think that this is
because
> > of the existing code. Chris, Eric, Russell and the others did a great
job.
> > I think it is an essential shortcoming of the way zip files are designed
> > and urge to stay compatible with it. I have the impression that the zip
> > format was designed for batch file processing and not so much for single
> > file operations, (ie to rename a file you must to rewrite the whole zip
> file).
> >
> > A thought came to my mind. What about a new format, which uses still the
> > proven compression methods (and allows for adding new methods) but
stores
> > the files in a different structure, which makes single file access more
> > convinient and allows for all sorts of options which are now difficult
to
> > achieve. Something like a 'file-object database'.
> >
> > We would lose compatibility with the zip format, but for many
> applications,
> > except for the Winzip clones (this is not meant negative - I have my own
> > Winzip clone :^), this might not be such a big problem.
> > We could use very much of the experience we have to design a new format.
> >
> > What are your thoughts ?
> > Does this sound crazy, asking for trouble, an effort only for someone
who
> > has nothing else to do or might this be a good idea ?
> > What are the fundamental problems and shortcomings you encounter, what
are
> > your wishlists ?
> >
> > Please your reactions,
> > Regards, Gerard.
> >
> >
> >
> >
> >
> >
>
>
>
Other related posts:
