initscripts: Properly handle new timestamp format

Submitted by Gary Thomas on March 1, 2012, 2:43 p.m.

Details

Message ID 1330612994-26329-1-git-send-email-gary@mlbassoc.com
State New
Headers show

Commit Message

Gary Thomas March 1, 2012, 2:43 p.m.
Recent changes have attempted to make consistant use of /etc/timestamp
In particular
  5aab665 initscripts: Make /etc/timestamp consistent again.
  173a48f image.bbclass: Ensure timestamp matches format used in initscripts after recent changes

This new format can cause problems as the value is too large for
most [32 bit] machines.  Work around this by only comparing the
YYYYMMDD portion (which does fit in 32 bits).  Also, the new format
is not directly compatible with the 'date' command line, so it
must be reformatted for use.

Signed-off-by: Gary Thomas <gary@mlbassoc.com>
---
 .../initscripts/initscripts-1.0/bootmisc.sh        |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

Patch hide | download patch | download mbox

diff --git a/meta/recipes-core/initscripts/initscripts-1.0/bootmisc.sh b/meta/recipes-core/initscripts/initscripts-1.0/bootmisc.sh
index 20ec0a0..383de82 100755
--- a/meta/recipes-core/initscripts/initscripts-1.0/bootmisc.sh
+++ b/meta/recipes-core/initscripts/initscripts-1.0/bootmisc.sh
@@ -70,8 +70,8 @@  if test -e /etc/timestamp
 then
 	SYSTEMDATE=`date -u +%4Y%2m%2d%2H%2M`
 	read TIMESTAMP < /etc/timestamp
-	if [ ${TIMESTAMP} -gt $SYSTEMDATE ]; then
-		date -u $TIMESTAMP
+	if [ ${TIMESTAMP%????} -gt ${SYSTEMDATE%????} ]; then
+		date -u ${TIMESTAMP#????}${TIMESTAMP%????????}
 		/etc/init.d/hwclock.sh stop
 	fi
 fi

Comments

Richard Purdie March 1, 2012, 2:59 p.m.
On Thu, 2012-03-01 at 07:43 -0700, Gary Thomas wrote:
> Recent changes have attempted to make consistant use of /etc/timestamp
> In particular
>   5aab665 initscripts: Make /etc/timestamp consistent again.
>   173a48f image.bbclass: Ensure timestamp matches format used in initscripts after recent changes
> 
> This new format can cause problems as the value is too large for
> most [32 bit] machines.  Work around this by only comparing the
> YYYYMMDD portion (which does fit in 32 bits).  Also, the new format
> is not directly compatible with the 'date' command line, so it
> must be reformatted for use.
> 
> Signed-off-by: Gary Thomas <gary@mlbassoc.com>
> ---
>  .../initscripts/initscripts-1.0/bootmisc.sh        |    4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)

I merged the changes to busybox in relation to this. Is this patch still
needed?

Cheers,

Richard
Gary Thomas March 1, 2012, 3:11 p.m.
On 2012-03-01 07:59, Richard Purdie wrote:
> On Thu, 2012-03-01 at 07:43 -0700, Gary Thomas wrote:
>> Recent changes have attempted to make consistant use of /etc/timestamp
>> In particular
>>    5aab665 initscripts: Make /etc/timestamp consistent again.
>>    173a48f image.bbclass: Ensure timestamp matches format used in initscripts after recent changes
>>
>> This new format can cause problems as the value is too large for
>> most [32 bit] machines.  Work around this by only comparing the
>> YYYYMMDD portion (which does fit in 32 bits).  Also, the new format
>> is not directly compatible with the 'date' command line, so it
>> must be reformatted for use.
>>
>> Signed-off-by: Gary Thomas<gary@mlbassoc.com>
>> ---
>>   .../initscripts/initscripts-1.0/bootmisc.sh        |    4 ++--
>>   1 files changed, 2 insertions(+), 2 deletions(-)
>
> I merged the changes to busybox in relation to this. Is this patch still
> needed?

Let me check - I didn't see the related busybox change.
Gary Thomas March 1, 2012, 3:27 p.m.
On 2012-03-01 08:11, Gary Thomas wrote:
> On 2012-03-01 07:59, Richard Purdie wrote:
>> On Thu, 2012-03-01 at 07:43 -0700, Gary Thomas wrote:
>>> Recent changes have attempted to make consistant use of /etc/timestamp
>>> In particular
>>> 5aab665 initscripts: Make /etc/timestamp consistent again.
>>> 173a48f image.bbclass: Ensure timestamp matches format used in initscripts after recent changes
>>>
>>> This new format can cause problems as the value is too large for
>>> most [32 bit] machines. Work around this by only comparing the
>>> YYYYMMDD portion (which does fit in 32 bits). Also, the new format
>>> is not directly compatible with the 'date' command line, so it
>>> must be reformatted for use.
>>>
>>> Signed-off-by: Gary Thomas<gary@mlbassoc.com>
>>> ---
>>> .../initscripts/initscripts-1.0/bootmisc.sh | 4 ++--
>>> 1 files changed, 2 insertions(+), 2 deletions(-)
>>
>> I merged the changes to busybox in relation to this. Is this patch still
>> needed?
>
> Let me check - I didn't see the related busybox change.
>

I missed the busybox change because there was no PR bump :-(

The problem with the change turning off CONFIG_FEATURE_DATE_COMPAT is that
now 'date' from busybox works one way and 'date' from coreutils works another.

Using coreutils:

root@cobra8148p81:~# date 201203011520
date: invalid date `201203011520'
root@cobra8148p81:~# date 030115202012
Thu Mar  1 15:20:00 UTC 2012
root@cobra8148p81:~# ls -l /bin/date
lrwxrwxrwx 1 root root 14 Mar  1 15:14 /bin/date -> date.coreutils

Using busybox:

root@cobra8148p81:~# ln -s /bin/busybox /tmp/date
root@cobra8148p81:~# /tmp/date 201203011520
Thu Mar  1 15:20:00 UTC 2012

I think the best thing would be to turn CONFIG_FEATURE_DATE_COMPAT back
on along with my reformatting change.

I can make an updated patch if you agree.
Richard Purdie March 1, 2012, 3:44 p.m.
On Thu, 2012-03-01 at 08:27 -0700, Gary Thomas wrote:
> On 2012-03-01 08:11, Gary Thomas wrote:
> > On 2012-03-01 07:59, Richard Purdie wrote:
> >> On Thu, 2012-03-01 at 07:43 -0700, Gary Thomas wrote:
> >>> Recent changes have attempted to make consistant use of /etc/timestamp
> >>> In particular
> >>> 5aab665 initscripts: Make /etc/timestamp consistent again.
> >>> 173a48f image.bbclass: Ensure timestamp matches format used in initscripts after recent changes
> >>>
> >>> This new format can cause problems as the value is too large for
> >>> most [32 bit] machines. Work around this by only comparing the
> >>> YYYYMMDD portion (which does fit in 32 bits). Also, the new format
> >>> is not directly compatible with the 'date' command line, so it
> >>> must be reformatted for use.
> >>>
> >>> Signed-off-by: Gary Thomas<gary@mlbassoc.com>
> >>> ---
> >>> .../initscripts/initscripts-1.0/bootmisc.sh | 4 ++--
> >>> 1 files changed, 2 insertions(+), 2 deletions(-)
> >>
> >> I merged the changes to busybox in relation to this. Is this patch still
> >> needed?
> >
> > Let me check - I didn't see the related busybox change.
> >
> 
> I missed the busybox change because there was no PR bump :-(
> 
> The problem with the change turning off CONFIG_FEATURE_DATE_COMPAT is that
> now 'date' from busybox works one way and 'date' from coreutils works another.
> 
> Using coreutils:
> 
> root@cobra8148p81:~# date 201203011520
> date: invalid date `201203011520'
> root@cobra8148p81:~# date 030115202012
> Thu Mar  1 15:20:00 UTC 2012
> root@cobra8148p81:~# ls -l /bin/date
> lrwxrwxrwx 1 root root 14 Mar  1 15:14 /bin/date -> date.coreutils
> 
> Using busybox:
> 
> root@cobra8148p81:~# ln -s /bin/busybox /tmp/date
> root@cobra8148p81:~# /tmp/date 201203011520
> Thu Mar  1 15:20:00 UTC 2012
> 
> I think the best thing would be to turn CONFIG_FEATURE_DATE_COMPAT back
> on along with my reformatting change.
> 
> I can make an updated patch if you agree.

Is this going to cause us a problem in real world usage? I'd hope in the
general case we use standard formatting?

I have to admit I'm getting more than a little frustrated with what
seems like a continual set of changes bouncing this format around in
different directions :(.

Cheers,

Richard
Gary Thomas March 1, 2012, 3:52 p.m.
On 2012-03-01 08:44, Richard Purdie wrote:
> On Thu, 2012-03-01 at 08:27 -0700, Gary Thomas wrote:
>> On 2012-03-01 08:11, Gary Thomas wrote:
>>> On 2012-03-01 07:59, Richard Purdie wrote:
>>>> On Thu, 2012-03-01 at 07:43 -0700, Gary Thomas wrote:
>>>>> Recent changes have attempted to make consistant use of /etc/timestamp
>>>>> In particular
>>>>> 5aab665 initscripts: Make /etc/timestamp consistent again.
>>>>> 173a48f image.bbclass: Ensure timestamp matches format used in initscripts after recent changes
>>>>>
>>>>> This new format can cause problems as the value is too large for
>>>>> most [32 bit] machines. Work around this by only comparing the
>>>>> YYYYMMDD portion (which does fit in 32 bits). Also, the new format
>>>>> is not directly compatible with the 'date' command line, so it
>>>>> must be reformatted for use.
>>>>>
>>>>> Signed-off-by: Gary Thomas<gary@mlbassoc.com>
>>>>> ---
>>>>> .../initscripts/initscripts-1.0/bootmisc.sh | 4 ++--
>>>>> 1 files changed, 2 insertions(+), 2 deletions(-)
>>>>
>>>> I merged the changes to busybox in relation to this. Is this patch still
>>>> needed?
>>>
>>> Let me check - I didn't see the related busybox change.
>>>
>>
>> I missed the busybox change because there was no PR bump :-(
>>
>> The problem with the change turning off CONFIG_FEATURE_DATE_COMPAT is that
>> now 'date' from busybox works one way and 'date' from coreutils works another.
>>
>> Using coreutils:
>>
>> root@cobra8148p81:~# date 201203011520
>> date: invalid date `201203011520'
>> root@cobra8148p81:~# date 030115202012
>> Thu Mar  1 15:20:00 UTC 2012
>> root@cobra8148p81:~# ls -l /bin/date
>> lrwxrwxrwx 1 root root 14 Mar  1 15:14 /bin/date ->  date.coreutils
>>
>> Using busybox:
>>
>> root@cobra8148p81:~# ln -s /bin/busybox /tmp/date
>> root@cobra8148p81:~# /tmp/date 201203011520
>> Thu Mar  1 15:20:00 UTC 2012
>>
>> I think the best thing would be to turn CONFIG_FEATURE_DATE_COMPAT back
>> on along with my reformatting change.
>>
>> I can make an updated patch if you agree.
>
> Is this going to cause us a problem in real world usage? I'd hope in the
> general case we use standard formatting?
>
> I have to admit I'm getting more than a little frustrated with what
> seems like a continual set of changes bouncing this format around in
> different directions :(.

I agree and I'm sorry I missed this in my first change - I was just
trying to make the time stamps be consistent.

As far as I can recall (which is a really long time), 'date' has always
wanted the format MMDDHHmm[YYYY], so I think that's what we should expect.
That format doesn't compare easily which is why the timestamp was changed
(not by me) to a more ISO standard YYYYMMDDHHmm.  If busybox has 64-bit
math enabled, then this can be compared with no problems, it just has
to be munged into the format 'date' wants.
Otavio Salvador March 1, 2012, 4:01 p.m.
On Thu, Mar 1, 2012 at 12:27, Gary Thomas <gary@mlbassoc.com> wrote:
> I think the best thing would be to turn CONFIG_FEATURE_DATE_COMPAT back
> on along with my reformatting change.
>
> I can make an updated patch if you agree.

This is indeed the better solution.

Please send an updated patch in meanwhile so Richard can apply it once
he has some time and restore the right behavior.
Otavio Salvador March 1, 2012, 4:04 p.m.
On Thu, Mar 1, 2012 at 12:52, Gary Thomas <gary@mlbassoc.com> wrote:
> On 2012-03-01 08:44, Richard Purdie wrote:
>> Is this going to cause us a problem in real world usage? I'd hope in the
>> general case we use standard formatting?
>>
>> I have to admit I'm getting more than a little frustrated with what
>> seems like a continual set of changes bouncing this format around in
>> different directions :(.
>
> I agree and I'm sorry I missed this in my first change - I was just
> trying to make the time stamps be consistent.
>
> As far as I can recall (which is a really long time), 'date' has always
> wanted the format MMDDHHmm[YYYY], so I think that's what we should expect.
> That format doesn't compare easily which is why the timestamp was changed
> (not by me) to a more ISO standard YYYYMMDDHHmm.  If busybox has 64-bit
> math enabled, then this can be compared with no problems, it just has
> to be munged into the format 'date' wants.

So we can have compat and 64-bit math and have it properly behaving?
Gary Thomas March 1, 2012, 4:06 p.m.
On 2012-03-01 09:04, Otavio Salvador wrote:
> On Thu, Mar 1, 2012 at 12:52, Gary Thomas<gary@mlbassoc.com>  wrote:
>> On 2012-03-01 08:44, Richard Purdie wrote:
>>> Is this going to cause us a problem in real world usage? I'd hope in the
>>> general case we use standard formatting?
>>>
>>> I have to admit I'm getting more than a little frustrated with what
>>> seems like a continual set of changes bouncing this format around in
>>> different directions :(.
>>
>> I agree and I'm sorry I missed this in my first change - I was just
>> trying to make the time stamps be consistent.
>>
>> As far as I can recall (which is a really long time), 'date' has always
>> wanted the format MMDDHHmm[YYYY], so I think that's what we should expect.
>> That format doesn't compare easily which is why the timestamp was changed
>> (not by me) to a more ISO standard YYYYMMDDHHmm.  If busybox has 64-bit
>> math enabled, then this can be compared with no problems, it just has
>> to be munged into the format 'date' wants.
>
> So we can have compat and 64-bit math and have it properly behaving?

Yes, I believe so.  I'll work up the patch and test it now.
Lauri Hintsala March 2, 2012, 6:15 a.m.
On 03/01/2012 06:06 PM, Gary Thomas wrote:
>>> As far as I can recall (which is a really long time), 'date' has always
>>> wanted the format MMDDHHmm[YYYY], so I think that's what we should
>>> expect.
>>> That format doesn't compare easily which is why the timestamp was
>>> changed
>>> (not by me) to a more ISO standard YYYYMMDDHHmm. If busybox has 64-bit
>>> math enabled, then this can be compared with no problems, it just has
>>> to be munged into the format 'date' wants.
>>
>> So we can have compat and 64-bit math and have it properly behaving?
>
> Yes, I believe so. I'll work up the patch and test it now.


It might be very helpful for other developers if 64-bit math requirement 
of busybox would be documented somewhere.

BR,
Lauri