[fpc-devel] Abbrevia Port (was: Portability Standards)
Michael Van Canneyt
michael at freepascal.org
Tue Jan 4 11:39:41 CET 2005
On Tue, 4 Jan 2005, DrDiettrich wrote:
> Michael Van Canneyt wrote:
> > > Question: What's preferrable, a direct port of the Abbrevia library, or
> > > a new and better portable design instead, that interfaces with the not
> > > otherwise available worker classes as implemented in Abbrevia?
> > Second option.
> Here's my general idea of an Abbrevia compatible redesign:
> The working name for this new project is Directories+DirectoryItems,
> with a "di" prefix for the unit names etc. The project unifies the
> handling of archives, compressed and encrypted files.
> The basic objects are Directories and DirectoryItems. This should allow
> to cover the file systems of all platforms, as well as archive files,
> networks etc.
> Directories are DirectoryItems themselves (subdirectories), in general
> containers for DirectoryItems, with according management functions. One
> method allows to enumerate all contained DirectoryItems. A callback
> function can process the items and signal abort (when the file is found)
> or recurse (into a subdirectory). This IMO is a better replacement for
> the FindFirst/FindNext/FindClose crap, applicable also to the contents
> of archive files.
On the condition that you also implement by default also a method returning
a TList or TStringList with TDirectoryItems. Not everyone is comfortable
with callbacks. The TList/TStringlist method should work fine for not-too-large
> Other DirectoryItems are files and links.
> Links transparently wrap the linked file for file related operations,
> and have additional methods for managing the links themselves
> File items can be opened and closed, open files have an according Stream
> Archive files must be mappable into Directories, somehow. A Mount method
> might return the appropriate Directory object for the files inside an
This seems all pretty much OK.
> On Posix (Unix?) file systems the ownership (UID, GID) as well as
> specific file (executable...) and directory (sticky...) attributes are
> important, when extracting files from archives. Does FPC already provide
> according portable access and management procedures?
We have stuck to the lowest common denominator, i.e. Windows,
mainly for compatibility reasons.
I think that if we're going to be having a new implementation, we should go
for the maximum, and provide sensible defaults for the 'lesser' OS-es.
More information about the fpc-devel