TC7.55a does not handle correctly the case when there is more than one file with the same name is in the packed archive file. On the first run when the archive is opened the ReadHeader()/ProcessFile(..., PK_SKIP, ...) is called as expected. However, when a filename appears multiple times in the archive (which is possible in case of Unix archieve) then the ReadHeader()/ProcessFile(..., PK_EXTRACT, ...) is called for the first filename like the selected one, not the selected file itself.
There is one workaround: if two of the files are selected, then the second file can be copied out from the archive (overwriting the first one).
The detailed description of the problem can be found in the ar-plugin announcement thread.
Packer plugin: more than one file with the same name
Moderators: Hacker, petermad, Stefan2, white
-
ghisler(Author)
- Site Admin
- Posts: 50475
- Joined: 2003-02-04, 09:46 UTC
- Location: Switzerland
- Contact:
Multiple objects with the same name are currently not supported. Why? TC distinguishes files/folders by their name, not by any order in which they are reported by the plugin. This is necessary because the file to which the plugins accesses may be changed by some other process, which could completely change the file order.
Author of Total Commander
https://www.ghisler.com
https://www.ghisler.com
OK, I see that the current version of TC distinguishes the files/folders by their name.
There is, however, some hope that it is not so difficult to support files with the same name. Looking at the Packer plugin Interface Description 2.21, at the ReadHeader() function of the plugin fills a lot of information in the tHeaderData about the file like PackSize, UnpSize, FileCRC and FileTime to menention the most important ones. There are even fields for providing extra file comment information about the file by the plugin, see fields CmtBuf, CmtBufSize, CmtSize and CmtState.
When it comes to the time when OpenArchieve() is called with ArchiveData->OpenMode=PK_OM_EXTRACT, the ProcessFile() is called with PK_EXTRACT. The plugin could decide whether it needs more information about the file to be processed. More information is needed for example because the plugin maintains a "multiple filenames" list, and the position in the archive points to an ambigous filename. At this point the plugin may ask TC to provide more information about the file to be processed, for example the tHeaderData which was given to TC earlier. Then the plugin may decide to extract the file and return with 0 (success) because the tHeaderData matches or return a new error code which signals to TC that this was not the right file and it should go on to process the archive.
By the way, comparing the tHeaderData could be done at TC side, too. This data is provided by the plugin's ReadHeader() in the first loop when OpenArchieve() is called with ArchiveData->OpenMode=PK_OM_LIST and the ProcessFile() was called with PK_SKIP every time. When it comes to the second reading of the archive (OpenMode=PK_OM_EXTRACT) and the ReadHeader() of the plugin is again computing the tHeaderData then the two contents of the tHeaderData can be compared. When there is a match then TC can be sure that the plugin would extract the right file asked by the user. There could be a new PK_CAPS_ value which would be returned by GetPackerCaps() function of the plugin which could enable this strict file matching operation of TC.
What do you think?
There is, however, some hope that it is not so difficult to support files with the same name. Looking at the Packer plugin Interface Description 2.21, at the ReadHeader() function of the plugin fills a lot of information in the tHeaderData about the file like PackSize, UnpSize, FileCRC and FileTime to menention the most important ones. There are even fields for providing extra file comment information about the file by the plugin, see fields CmtBuf, CmtBufSize, CmtSize and CmtState.
When it comes to the time when OpenArchieve() is called with ArchiveData->OpenMode=PK_OM_EXTRACT, the ProcessFile() is called with PK_EXTRACT. The plugin could decide whether it needs more information about the file to be processed. More information is needed for example because the plugin maintains a "multiple filenames" list, and the position in the archive points to an ambigous filename. At this point the plugin may ask TC to provide more information about the file to be processed, for example the tHeaderData which was given to TC earlier. Then the plugin may decide to extract the file and return with 0 (success) because the tHeaderData matches or return a new error code which signals to TC that this was not the right file and it should go on to process the archive.
By the way, comparing the tHeaderData could be done at TC side, too. This data is provided by the plugin's ReadHeader() in the first loop when OpenArchieve() is called with ArchiveData->OpenMode=PK_OM_LIST and the ProcessFile() was called with PK_SKIP every time. When it comes to the second reading of the archive (OpenMode=PK_OM_EXTRACT) and the ReadHeader() of the plugin is again computing the tHeaderData then the two contents of the tHeaderData can be compared. When there is a match then TC can be sure that the plugin would extract the right file asked by the user. There could be a new PK_CAPS_ value which would be returned by GetPackerCaps() function of the plugin which could enable this strict file matching operation of TC.
What do you think?