zfs discuss - Nov 2008 - Files from the future are not accessible on ZFS

Hi all,

It seems a user managed to create files dated Oct 16, 2057, from a Linux distro
that mounted by NFS the volumes on an x2100 server running S10U5, with ZFS
volumes.

The problem is, those files are completely unreachable on the S10 server:

# ls -l .gtk-bookmarks
.gtk-bookmarks: Value too large for defined data type

# more .gtk-bookmarks
.gtk-bookmarks: Value too large for defined data type

# cp .gtk-bookmarks /tmp
cp: cannot access .gtk-bookmarks

# touch .gtk-bookmarks
touch: .gtk-bookmarks cannot stat

# rm .gtk-bookmarks
.gtk-bookmarks: Value too large for defined data type

A truss shows this:
lstat64(".gtk-bookmarks", 0x08046A60)           Err#79 EOVERFLOW
>From a RHEL 4 NFS mount, it shows:
$ ls -l .gtk-bookmarks
-rw-r--r--+ 1 user opc 0 oct 16  2057 .gtk-bookmarks

Is that a ZFS bug or an lstat() one?

TIA,

Laurent
-- 
This message posted from opensolaris.org

Laurent Blume <laurent at elanor.org> wrote:
> Hi all,
>
> It seems a user managed to create files dated Oct 16, 2057, from a Linux
distro that mounted by NFS the volumes on an x2100 server running S10U5, with
ZFS volumes.
>
> The problem is, those files are completely unreachable on the S10 server:
You need 64 bit programs to access these files.


J?rg

-- 
 EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin
       js at cs.tu-berlin.de                (uni)  
       schilling at fokus.fraunhofer.de     (work) Blog:
http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily

Laurent Blume wrote:
> Hi all,
> 
> It seems a user managed to create files dated Oct 16, 2057, from a Linux
distro that mounted by NFS the volumes on an x2100 server running S10U5, with
ZFS volumes.
> 
> The problem is, those files are completely unreachable on the S10 server:
> 
> # ls -l .gtk-bookmarks
> .gtk-bookmarks: Value too large for defined data type
> 
> # more .gtk-bookmarks
> .gtk-bookmarks: Value too large for defined data type
> 
> # cp .gtk-bookmarks /tmp
> cp: cannot access .gtk-bookmarks
> 
> # touch .gtk-bookmarks
> touch: .gtk-bookmarks cannot stat
> 
The touch utility was modified a few months ago to deal with out of 
range timestamps.

PSARC 2008/508 allow touch/settime to fix out of range timestamps
6709455 settime should be able to manipulate files with wrong timestamp


    -Mark

I see, thanks.
And as J?rg said, I only need a 64 bit binary. I didn''t know, but there
is one for ls, and it does work as expected:

$ /usr/bin/amd64/ls -l  .gtk-bookmarks
-rw-r--r--   1 user opc            0 oct. 16  2057 .gtk-bookmarks

This is a bit absurd. I thought Solaris was fully 64 bit. I hope those tools
will be integrated soon.

Thanks for the pointers!

Laurent
-- 
This message posted from opensolaris.org

> I see, thanks.
> And as J?rg said, I only need a 64 bit binary. I
> didn''t know, but there is one for ls, and it does
> work as expected:
> 
> $ /usr/bin/amd64/ls -l  .gtk-bookmarks
> -rw-r--r--   1 user opc            0 oct. 16  2057
> .gtk-bookmarks
> 
> This is a bit absurd. I thought Solaris was fully 64
> bit. I hope those tools will be integrated soon.
> 
I am not sure if this is expected, I thought ls should be actually a hard link
to isaexec and system picks applicable ISA transparently?

indeed wierd.

Ivan.
> Thanks for the pointers!
> 
> Laurent
-- 
This message posted from opensolaris.org

On Tue, Nov 04, 2008 at 05:52:33AM -0800, Ivan Wang
wrote:
> > $ /usr/bin/amd64/ls -l  .gtk-bookmarks
> > -rw-r--r--   1 user opc            0 oct. 16  2057
> > .gtk-bookmarks
> > 
> > This is a bit absurd. I thought Solaris was fully 64
> > bit. I hope those tools will be integrated soon.
Solaris runs on non-64bit capable hardware, and it doesn''t use fat
binaries, so both 32-bit and 64-bit binaries exist in some cases.
> I am not sure if this is expected, I thought ls should be actually a
> hard link to isaexec and system picks applicable ISA transparently?
I think that will work, but isaexec is not free for execution time.  My
guess is that someone decided that the execution cost wasn''t worth it.
But I have no evidence if that''s the real reason.

However, as a test, I created a 2038+ timestamp file on zfs, verified
that /usr/bin/ls would fail to display it, and I moved /usr/bin/ls to
/usr/bin/i86/ls and linked /usr/lib/isaexec to /usr/bin/ls.  (Move it to
/usr/bin/sparcv7/ls on a SPARC host).

/usr/bin/ls now automatically finds and runs the 64-bit version and
displays the file just fine.  I made no attempt to calculate how much
longer it takes to run now.

-- 
Darren