Re: [fpc-devel] Abbrevia Port (was: Portability Standards)
On Thu, 6 Jan 2005, DrDiettrich wrote: > Michael Van Canneyt wrote: > > > > method allows to enumerate all contained DirectoryItems. > ... > > 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. > > It's not a matter of the lists, it's a matter of the required > processing. When it takes the same time to build the list than to > extract or decrypt all files, then one may prefer *not* to wait for the > list before simply extracting all files. > > Of course it's always possible to build a file list, with a simple > procedure that wraps the enumeration procedure. This is what I had in mind. > > > > > 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. > > Could you imagine a procedure that gets an record with file attributes, > as found in an archive, and then does the best with regards to the > actual host system? I could write such a procedure for both Windows and > e.g. Linux, provided the required OS calls are available. Would that > mean that I had to use libc for the Unix part? Using Unix/Baseunix, yes, this would be fine. Note that not all attributes can be set. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Abbrevia Port (was: Portability Standards)
Michael Van Canneyt wrote: > > method allows to enumerate all contained DirectoryItems. ... > 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. It's not a matter of the lists, it's a matter of the required processing. When it takes the same time to build the list than to extract or decrypt all files, then one may prefer *not* to wait for the list before simply extracting all files. Of course it's always possible to build a file list, with a simple procedure that wraps the enumeration procedure. > > 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. Could you imagine a procedure that gets an record with file attributes, as found in an archive, and then does the best with regards to the actual host system? I could write such a procedure for both Windows and e.g. Linux, provided the required OS calls are available. Would that mean that I had to use libc for the Unix part? DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Abbrevia Port (was: Portability Standards)
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
Re: [fpc-devel] Abbrevia Port (was: Portability Standards)
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. 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. 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? DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
