[OpenAFS-devel] Solaris-8/64-bit problem with mtime = Jan 1 1970

[Ole Benner]

Derek Atkins wrote:
> 
> As I said, this is a problem because you are trying to, effectively,
> set a time _BEFORE_ the epoch.  You can't do that on some platforms;
> it is an undefined operation.

I am not convinced that it is the case but I cannot prove othervice.
What doesn't make sense is that the same platform (sun4x_58) and the
exact same binaries except from the kernel module (libafs64.nonfs.o
versus libafs.nonfs.o) on identical configured SUNs behaves differently.


> I don't think I want to know WHY you even trying to set a date/time
> to 1970.  But if you can show me the problem with any other date, then
> I'll consider it a bug.  Otherwise, I consider this a "don't do that"
> situation.

I don't want to set the date back to 1970 but I suddently had some files
with that date and I don't know how I got the. Maybe from some bad
behaving program or from a FAS client with clock out of sync (Maybe W2k
AFS client). I couldn't find a reason for the date on the files, but I
discovered that 'touch filename' on my Linux box fixed the problem. Then
I started investigating.

What I really doesn't like is that it is possible with such simple
command to make a file unaccessible and if I don't have an AFS client
that can see the file I cannot get it back. Once the file has the
mentioned date I cannot touch it again on my 64bit host. It is gone...

/Ole

 
> -derek
> 
> Ole Benner <olb@kom.auc.dk> writes:
> 
> > Both hosts is in same timezone. We are 1 hour east of GMT + 1 hour
> > daylight saving:
> >
> > olb@zil:[olb]$ date
> > Mon Jul  9 15:30:04 MEST 2001
> > olb@zil:[olb]$ date -u
> > Mon Jul  9 13:30:06 GMT 2001
> >
> > On host 'zil' I can produce the problem like this:
> >
> > olb@zil:[olb]$ ls -l test
> > -rw-rw-r--   1 olb      olb            0 Jul  9 15:28 test
> > olb@zil:[olb]$ touch -t 197001010000 test
> > olb@zil:[olb]$ ls -l test
> > test: Value too large for defined data type
> >
> > 'zil' is a Sun Blade 1000 UltraSPARC-III running Solaris-8/64bit. I have
> > an identical configured Sun SPARCstation-5 running Solaris-8/32bit which
> > can see the file allright:
> >
> > olb@tatra:[olb]$ ls -l test
> > -rw-rw-r--   1 olb      olb            0 Jan  1  1970 test
> >
> > They are identicaly installed with junpstart and running the same
> > compiled version of OpenAFS except that the SS-5 uses the 32-bit version
> > og the afs kernel module.
> >
> > /Ole
> >
> >
> > Derek Atkins wrote:
> > >
> > > Are both machines in the same Time Zone?  It looks like the machine
> > > creating the file (remember, touch creates the file in the LOCAL
> > > timezone, but stores the information in GMT).  This means that the
> > > earliest time value you can store is 0000, 1 Jan 1970 GMT.  Assuming
> > > you are NOT in GMT, then trying to store 197001010000 could cause a
> > > problem, especially if you are east of GMT.
> > >
> > > It's possible that you are storing a negative time value for that
> > > first hour, and the negative value is being really confusing to the
> > > 64-bit machine.
> > >
> > > -derek
> > >
> > > Ole Benner <olb@kom.auc.dk> writes:
> > >
> > > > Hi,
> > > >
> > > > I have just discovered a problem on our OpenAFS client on
> > > > Solaris-8/64bit. If I make a file on another platform with date "Jan 1
> > > > 1970" and I try to stat it on Sol-8 I get this error:
> > > >
> > > > On Linux w/ OpenAFS 1.0.4:
> > > > --------------------------
> > > > olb@bsa:[olb]$ touch -t 197001010000 test
> > > > olb@bsa:[olb]$ ls -l test
> > > > -rw-rw-r--    1 olb      olb             0 Jan  1  1970 test
> > > >
> > > > On Solaris-8/64bit with OpenAFS 1.0.4:
> > > > --------------------------------------
> > > > olb@ara:[olb]$ ls -l test
> > > > test: Value too large for defined data type
> > > >
> > > > On Solaris-8/32bit there is no problem. A time value up to 197001010059
> > > > failes on Sol-8/64bit and from 197001010100 and forward it is all right.
> > > >
> > > > Has anyone alse seen that ?
> > > >
> > > > Regards
> > > >
> > > > Ole Benner
> > > > System administrator
> > > > Aalborg University
> > > > IES, KOM-dept.
> > > > _______________________________________________
> > > > OpenAFS-devel mailing list
> > > > OpenAFS-devel@openafs.org
> > > > https://lists.openafs.org/mailman/listinfo/openafs-devel
> > >
> > > --
> > >        Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
> > >        Member, MIT Student Information Processing Board  (SIPB)
> > >        URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
> > >        warlord@MIT.EDU                        PGP key available
> 
> --
>        Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
>        Member, MIT Student Information Processing Board  (SIPB)
>        URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
>        warlord@MIT.EDU                        PGP key available