aboutsummaryrefslogtreecommitdiff
path: root/pkg/ctime
Commit message (Collapse)AuthorAge
* Replace deprecated ioutilChris Evich2022-09-20
| | | | | | | | | | Package `io/ioutil` was deprecated in golang 1.16, preventing podman from building under Fedora 37. Fortunately, functionality identical replacements are provided by the packages `io` and `os`. Replace all usage of all `io/ioutil` symbols with appropriate substitutions according to the golang docs. Signed-off-by: Chris Evich <cevich@redhat.com>
* golangci-lint: enable nolintlintPaul Holzinger2022-06-14
| | | | | | | | | | The nolintlint linter does not deny the use of `//nolint` Instead it allows us to enforce a common nolint style: - force that a linter name must be specified - do not add a space between `//` and `nolint` - make sure nolint is only used when there is actually a problem Signed-off-by: Paul Holzinger <pholzing@redhat.com>
* go fmt: use go 1.18 conditional-build syntaxValentin Rothberg2022-03-18
| | | | Signed-off-by: Valentin Rothberg <vrothberg@redhat.com>
* Re-add int64 casts for ctimeMatthew Heon2019-07-23
| | | | | | | | | The variables here are 64-bit on 64-bit builds, so the linter recommends stripping them. Unfortunately, they're 32-bit on 32-bit builds, so stripping them breaks that. Readd with a nolint to convince it to not break. Signed-off-by: Matthew Heon <mheon@redhat.com>
* golangci-lint round #3baude2019-07-21
| | | | | | | this is the third round of preparing to use the golangci-lint on our code base. Signed-off-by: baude <bbaude@redhat.com>
* ctime: Drop 32-/64-bit distinction on LinuxW. Trevor King2018-07-07
| | | | | | | | | | | We added the explicit int64 casts for 32-bit builds in 35e1ad78 (Make libpod build on 32-bit systems, 2018-02-12, #324), but the explicit casts work fine on 64-bit systems too. Signed-off-by: W. Trevor King <wking@tremily.us> Closes: #1058 Approved by: mheon
* pkg/ctime: Factor libpod/finished* into a separate packageW. Trevor King2018-07-06
This removes some boilerplate from the libpod package, so we can focus on container stuff there. And it gives us a tidy sub-package for focusing on ctime extraction, so we can focus on unit testing and portability of the extraction utility there. For the unsupported implementation, I'm falling back to Go's ModTime [1]. That's obviously not the creation time, but it's likely to be closer than the uninitialized Time structure from cc6f0e85 (more changes to compile darwin, 2018-07-04, #1047). Especially for our use case in libpod/oci, where we're looking at write-once exit files. The test is more complicated than I initially expected, because on Linux filesystem timestamps come from a truncated clock without interpolation [2] (and network filesystems can be completely decoupled [3]). So even for local disks, creation times can be up to a jiffie earlier than 'before'. This test ensures at least monotonicity by creating two files and ensuring the reported creation time for the second is greater than or equal to the reported creation time for the first. It also checks that both creation times are within the window from one second earlier than 'before' through 'after'. That should be enough of a window for local disks, even if the kernel for those systems has an abnormally large jiffie. It might be ok on network filesystems, although it will not be very resilient to network clock lagging behind the local system clock. [1]: https://golang.org/pkg/os/#FileInfo [2]: https://groups.google.com/d/msg/linux.kernel/mdeXx2TBYZA/_4eJEuJoAQAJ Subject: Re: Apparent backward time travel in timestamps on file creation Date: Thu, 30 Mar 2017 20:20:02 +0200 Message-ID: <tqMPU-1Sb-21@gated-at.bofh.it> [3]: https://groups.google.com/d/msg/linux.kernel/mdeXx2TBYZA/cTKj4OBuAQAJ Subject: Re: Apparent backward time travel in timestamps on file creation Date: Thu, 30 Mar 2017 22:10:01 +0200 Message-ID: <tqOyl-36A-1@gated-at.bofh.it> Signed-off-by: W. Trevor King <wking@tremily.us> Closes: #1050 Approved by: mheon