I think (not 100% sure) I discovered an issue with the mkzip package.Hi,
I'm packing files into an 7z archive using mkzip.
Unpacking the files is done in Windows using the 7z file manager.
The result is that many files have 1 sec mtime difference compared to the original.
After analysing the code, I think the issue could be related to this function below, which gets the "file mtime" for each source file and sets the result as the new mtime property to the compressed file:
proc ::zipfile::mkzip::timet_to_dos {time_t} {
set s [clock format $time_t -format {%Y %m %e %k %M %S}]
scan $s {%d %d %d %d %d %d} year month day hour min sec
expr {(($year-1980) << 25) | ($month << 21) | ($day << 16)
| ($hour << 11) | ($min << 5) | ($sec >> 1)}
}
I don't quite understand how the code works but could if be that it leads to 1 sec difference to the input variable?
Many thanks
Alexandru
Hi,
if you look at the last term
proc ::zipfile::mkzip::timet_to_dos {time_t} {^^^^^^^^^
set s [clock format $time_t -format {%Y %m %e %k %M %S}]
scan $s {%d %d %d %d %d %d} year month day hour min sec
expr {(($year-1980) << 25) | ($month << 21) | ($day << 16)
| ($hour << 11) | ($min << 5) | ($sec >> 1)}
}you see that the seconds are shifted right one position, that is they
are divided by 2 - I'd say it is intentional.
Helmut
proc ::zipfile::mkzip::timet_to_dos {time_t} {
set s [clock format $time_t -format {%Y %m %e %k %M %S}]
scan $s {%d %d %d %d %d %d} year month day hour min sec
expr {(($year-1980) << 25) | ($month << 21) | ($day << 16)
| ($hour << 11) | ($min << 5) | ($sec >> 1)}
}you see that the seconds are shifted right one position, that is they
Helmut Giese schrieb am Mittwoch, 22. Dezember 2021 um 23:37:12 UTC+1:
Hi,
if you look at the last term
proc ::zipfile::mkzip::timet_to_dos {time_t} {^^^^^^^^^
set s [clock format $time_t -format {%Y %m %e %k %M %S}]
scan $s {%d %d %d %d %d %d} year month day hour min sec
expr {(($year-1980) << 25) | ($month << 21) | ($day << 16)
| ($hour << 11) | ($min << 5) | ($sec >> 1)}
}you see that the seconds are shifted right one position, that is they
are divided by 2 - I'd say it is intentional.
Helmut
Okay, so why would this be intentional?
Can this function be modified, so that the mtime is preserved?
Alexandru <alexandr...@meshparts.de> wrote:
Helmut Giese schrieb am Mittwoch, 22. Dezember 2021 um 23:37:12 UTC+1:
Hi,
if you look at the last term
proc ::zipfile::mkzip::timet_to_dos {time_t} {^^^^^^^^^
set s [clock format $time_t -format {%Y %m %e %k %M %S}]
scan $s {%d %d %d %d %d %d} year month day hour min sec
expr {(($year-1980) << 25) | ($month << 21) | ($day << 16)
| ($hour << 11) | ($min << 5) | ($sec >> 1)}
}you see that the seconds are shifted right one position, that is they
are divided by 2 - I'd say it is intentional.
Helmut
Okay, so why would this be intentional?Because the zip format uses the MS-DOS time storage format, and for
MS-DOS time storage format the resolution of the time is two seconds.
Can this function be modified, so that the mtime is preserved?No, because it is inherent in the zip format, the mkzip package is
simply adhering to the zip format requirements.
If you want perfectly accurate mtime packaging and extraction you will
need to either use a different archive format that supports storing the
full time value, or you'll have to store the full times externally and
apply them manually after extracting from a zip.
Rich schrieb am Donnerstag, 23. Dezember 2021 um 04:39:08 UTC+1:
Alexandru <alexandr...@meshparts.de> wrote:
Helmut Giese schrieb am Mittwoch, 22. Dezember 2021 um 23:37:12 UTC+1:Because the zip format uses the MS-DOS time storage format, and for
Hi,
if you look at the last term
proc ::zipfile::mkzip::timet_to_dos {time_t} {^^^^^^^^^
set s [clock format $time_t -format {%Y %m %e %k %M %S}]
scan $s {%d %d %d %d %d %d} year month day hour min sec
expr {(($year-1980) << 25) | ($month << 21) | ($day << 16)
| ($hour << 11) | ($min << 5) | ($sec >> 1)}
}you see that the seconds are shifted right one position, that is they
are divided by 2 - I'd say it is intentional.
Helmut
Okay, so why would this be intentional?
MS-DOS time storage format the resolution of the time is two seconds.
Can this function be modified, so that the mtime is preserved?No, because it is inherent in the zip format, the mkzip package is
simply adhering to the zip format requirements.
If you want perfectly accurate mtime packaging and extraction you will
need to either use a different archive format that supports storing the
full time value, or you'll have to store the full times externally and
apply them manually after extracting from a zip.
When I use the 7z file manager (under Windows) the time stamps are
preserved, so the 7z format supports this.
The questions is: Is there a way in Tcl to create a 7z file with
correct time stamps? Maybe not using the zip package, maybe by
modifying the package.
Alexandru <alexandr...@meshparts.de> wrote:
Rich schrieb am Donnerstag, 23. Dezember 2021 um 04:39:08 UTC+1:
Alexandru <alexandr...@meshparts.de> wrote:
Helmut Giese schrieb am Mittwoch, 22. Dezember 2021 um 23:37:12 UTC+1: >> >> Hi,Because the zip format uses the MS-DOS time storage format, and for
if you look at the last term
proc ::zipfile::mkzip::timet_to_dos {time_t} {^^^^^^^^^
set s [clock format $time_t -format {%Y %m %e %k %M %S}]
scan $s {%d %d %d %d %d %d} year month day hour min sec
expr {(($year-1980) << 25) | ($month << 21) | ($day << 16)
| ($hour << 11) | ($min << 5) | ($sec >> 1)}
}you see that the seconds are shifted right one position, that is they >> >> are divided by 2 - I'd say it is intentional.
Helmut
Okay, so why would this be intentional?
MS-DOS time storage format the resolution of the time is two seconds.
Can this function be modified, so that the mtime is preserved?No, because it is inherent in the zip format, the mkzip package is
simply adhering to the zip format requirements.
If you want perfectly accurate mtime packaging and extraction you will
need to either use a different archive format that supports storing the
full time value, or you'll have to store the full times externally and
apply them manually after extracting from a zip.
When I use the 7z file manager (under Windows) the time stamps are preserved, so the 7z format supports this.7z is not zip. 7z is a newer archive format, and presumably it
supports higher resoultion timestamps than the MS-DOS timestamps used
in zip. [1]
The questions is: Is there a way in Tcl to create a 7z file withYes, when you (or someone else) writes the appropriate Tcl code module
correct time stamps? Maybe not using the zip package, maybe by
modifying the package.
to create a proper 7z file.
[1] The zip format was created in the MS-DOS days - so inheriting
MS-DOS's timestamp storage format made sense at that time. The
timestamp storage format has not been changed since (most likely in the
name of backwards compatibility.
Rich schrieb am Donnerstag, 23. Dezember 2021 um 18:27:20 UTC+1:
[1] The zip format was created in the MS-DOS days - so inheriting
MS-DOS's timestamp storage format made sense at that time. The
timestamp storage format has not been changed since (most likely in the
name of backwards compatibility.
I thought I'm already creating an archive in 7z format.
So the actual format is zip not the native 7z format?
Rich schrieb am Donnerstag, 23. Dezember 2021 um 18:27:20 UTC+1:
Alexandru <alexandr...@meshparts.de> wrote:
Rich schrieb am Donnerstag, 23. Dezember 2021 um 04:39:08 UTC+1:7z is not zip. 7z is a newer archive format, and presumably it
Alexandru <alexandr...@meshparts.de> wrote:
Okay, so why would this be intentional?Because the zip format uses the MS-DOS time storage format, and for
MS-DOS time storage format the resolution of the time is two seconds.
Can this function be modified, so that the mtime is preserved?No, because it is inherent in the zip format, the mkzip package is
simply adhering to the zip format requirements.
If you want perfectly accurate mtime packaging and extraction you will
need to either use a different archive format that supports storing the >> >> full time value, or you'll have to store the full times externally and
apply them manually after extracting from a zip.
When I use the 7z file manager (under Windows) the time stamps are
preserved, so the 7z format supports this.
supports higher resoultion timestamps than the MS-DOS timestamps used
in zip. [1]
The questions is: Is there a way in Tcl to create a 7z file withYes, when you (or someone else) writes the appropriate Tcl code module
correct time stamps? Maybe not using the zip package, maybe by
modifying the package.
to create a proper 7z file.
[1] The zip format was created in the MS-DOS days - so inheriting
MS-DOS's timestamp storage format made sense at that time. The
timestamp storage format has not been changed since (most likely in the
name of backwards compatibility.
I thought I'm already creating an archive in 7z format.
So the actual format is zip not the native 7z format?
Alexandru <alexandr...@meshparts.de> wrote:
Rich schrieb am Donnerstag, 23. Dezember 2021 um 18:27:20 UTC+1:
Alexandru <alexandr...@meshparts.de> wrote:
Rich schrieb am Donnerstag, 23. Dezember 2021 um 04:39:08 UTC+1:7z is not zip. 7z is a newer archive format, and presumably it
Alexandru <alexandr...@meshparts.de> wrote:
Okay, so why would this be intentional?Because the zip format uses the MS-DOS time storage format, and for
MS-DOS time storage format the resolution of the time is two seconds. >> >> > Can this function be modified, so that the mtime is preserved?
No, because it is inherent in the zip format, the mkzip package is
simply adhering to the zip format requirements.
If you want perfectly accurate mtime packaging and extraction you will >> >> need to either use a different archive format that supports storing the >> >> full time value, or you'll have to store the full times externally and >> >> apply them manually after extracting from a zip.
When I use the 7z file manager (under Windows) the time stamps are
preserved, so the 7z format supports this.
supports higher resoultion timestamps than the MS-DOS timestamps used
in zip. [1]
The questions is: Is there a way in Tcl to create a 7z file withYes, when you (or someone else) writes the appropriate Tcl code module
correct time stamps? Maybe not using the zip package, maybe by
modifying the package.
to create a proper 7z file.
[1] The zip format was created in the MS-DOS days - so inheriting
MS-DOS's timestamp storage format made sense at that time. The
timestamp storage format has not been changed since (most likely in the
name of backwards compatibility.
I thought I'm already creating an archive in 7z format.What are you creating the archive with? Your original post implied you
So the actual format is zip not the native 7z format?
were using Tcl's mkzip - which produces "zip" format archives.
Rich schrieb am Samstag, 25. Dezember 2021 um 04:05:54 UTC+1:
Alexandru <alexandr...@meshparts.de> wrote:
I thought I'm already creating an archive in 7z format.
So the actual format is zip not the native 7z format?
What are you creating the archive with? Your original post implied
you were using Tcl's mkzip - which produces "zip" format archives.
I don't remember exactly how I got this impression. It was obviously
wrong.
I thought the package cann also produce 7z archives. The ending of
the created archives is 7z so that was the missleading point.
Now I'm thinking: Maybe to just use the precompiles 7-zip executable
to create the archives instead mkzip.
Alexandru <alexandru.dadalau@meshparts.de> wrote:
Now I'm thinking: Maybe to just use the precompiles 7-zip executable
to create the archives instead mkzip.
If having perfect timestamps is important, then this is one way to go (although test to verify that actual 7z format archives do in fact
store full resolution timestamps).
On 26/12/2021 16:04, Rich wrote:
Alexandru <alexandr...@meshparts.de> wrote:
Now I'm thinking: Maybe to just use the precompiles 7-zip executable
to create the archives instead mkzip.
If having perfect timestamps is important, then this is one way to go (although test to verify that actual 7z format archives do in fact
store full resolution timestamps).
In addition to zip files, the 7z program can also process tgz files. Tar archives contain timestamps with at least 1 second resolution. So,
depending on your requirements, you may be able to use the tar package
from tcllib together with zlib to create compressed files that can be unpacked by 7z with correct time stamps.
Something along the lines of (untested):
package require tar
set fd [open output.tgz wb]
zlib push gzip $fd -level 9
tar::create $fd $files -chan
close $fd
Schelte.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 285 |
Nodes: | 16 (2 / 14) |
Uptime: | 24:13:20 |
Calls: | 6,448 |
Files: | 12,050 |
Messages: | 5,254,261 |