Opened 10 years ago
Last modified 4 years ago
#11176 reopened bug
[Tracker] status window displays Dec 13, 1901 as finish time
Reported by: | diver | Owned by: | waddlesplash |
---|---|---|---|
Priority: | normal | Milestone: | R1 |
Component: | Applications/Tracker | Version: | R1/Development |
Keywords: | Cc: | ||
Blocked By: | Blocking: | #6930, #14122 | |
Platform: | All |
Description
When emptying Trash with many small files Tracker status displays "Preparing to empty Trash" and it shows Finish: Dec 13, 1901.
Probably has something to do with Unixepoch:
The standard Unix time_t (data type representing a point in time) is a signed integer data type, traditionally of 32 bits (but see below), directly encoding the Unix time number as described in the preceding section. Being 32 bits means that it covers a range of about 136 years in total. The minimum representable time is 1901-12-13, and the maximum representable time is 2038-01-19.
Change History (8)
comment:1 by , 9 years ago
Blocking: | 6930 added |
---|
comment:2 by , 9 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
comment:3 by , 4 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
comment:4 by , 4 years ago
Well, it will now show "in several years", which is only slightly less wrong. We should still investigate why we get a nonsense duration for the copy.
comment:5 by , 4 years ago
Resolution: | fixed |
---|---|
Status: | closed → reopened |
comment:6 by , 4 years ago
Sorry for the drive-by-commenting, which is an easy way to be off-base, but just in case : this reminds me of a similar ticket (can't find it ATM) about moving files, which also produces silly dates.
It seems the date calculation routine expects to be fed bytes amounts, not file counts.
comment:8 by , 4 years ago
Blocking: | 14122 added |
---|
Fixed in hrev54149 (by PulkoMandy).