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 lists. > > 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 > (redirect...). > File items can be opened and closed, open files have an according Stream > object/property. > Archive files must be mappable into Directories, somehow. A Mount method > might return the appropriate Directory object for the files inside an > archive. This seems all pretty much OK. > > Question: > 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? No. 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. Michael. _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
