Q: return value of lseek64(fd, 0ULL, SEEK_END) - HP UX

This is a discussion on Q: return value of lseek64(fd, 0ULL, SEEK_END) - HP UX ; Hi, then man page of HP-UX 11.31 says lseek64() returns the same values (but larger ones maybe) as lseek() does. However lseek64(fd, 0ULL, SEEK_END) returns zero, where a value around 250GB was expected. The program had been compiled with hp-gcc ...

+ Reply to Thread
Results 1 to 7 of 7

Thread: Q: return value of lseek64(fd, 0ULL, SEEK_END)

  1. Q: return value of lseek64(fd, 0ULL, SEEK_END)

    Hi,

    then man page of HP-UX 11.31 says lseek64() returns the same values (but
    larger ones maybe) as lseek() does. However lseek64(fd, 0ULL, SEEK_END)
    returns zero, where a value around 250GB was expected.

    The program had been compiled with hp-gcc v4.2.1 (ia64-hp-hpux11.23) with option -D_LARGEFILE64_SOURCE
    (needed for prototypes) and included, producing a 32-bit
    executable.

    The program really was mean to explain, why a read() failed after a successful
    lseek64(fd, pos, SEEK_SET)...

    It seems there's something wrong.
    (Interestingly "what /usr/lib/hpux32/libc.so.1" reports
    "Unsupported_Internal_Version" for December 2006) so HP-UX 11.31 isn't
    finished yet?

    More interestingly, libdld.so.1 reports "B.12.41" dated September 2006.

    Wow, I already have HP-UX 12.41!!! ;-)

    Compiling with "-mlp64" to produce a 64-bit executable did not help.

    Any help?

    Regards,
    Ulrich

  2. Re: Q: return value of lseek64(fd, 0ULL, SEEK_END)

    Ulrich Windl wrote:
    > the man page of HP-UX 11.31 says lseek64() returns the same values (but
    > larger ones maybe) as lseek() does. However lseek64(fd, 0ULL, SEEK_END)
    > returns zero, where a value around 250GB was expected.


    Is your return type a off64_t?

    > (Interestingly "what /usr/lib/hpux32/libc.so.1" reports
    > "Unsupported_Internal_Version" for December 2006) so HP-UX 11.31 isn't
    > finished yet?


    It appears they forgot to remove it?

    > libdld.so.1 reports "B.12.41" dated September 2006.
    > Wow, I already have HP-UX 12.41!!! ;-)
    > Ulrich


    There is no connection between linker versions and HP-UX numbering.

  3. Re: Q: return value of lseek64(fd, 0ULL, SEEK_END)

    Dennis Handly writes:

    > Ulrich Windl wrote:
    >> the man page of HP-UX 11.31 says lseek64() returns the same values (but
    >> larger ones maybe) as lseek() does. However lseek64(fd, 0ULL, SEEK_END)
    >> returns zero, where a value around 250GB was expected.

    >
    > Is your return type a off64_t?


    I'm using printf("%llu", lseek64(...)). Should be OK.
    As this is actually tracking down a different problem, could it be that
    SEEK_END fails for a disk device? I'm trying to find out what the seekable
    range for a specific disk (RAID logical volume) is.

    >
    >> (Interestingly "what /usr/lib/hpux32/libc.so.1" reports
    >> "Unsupported_Internal_Version" for December 2006) so HP-UX 11.31 isn't
    >> finished yet?

    >
    > It appears they forgot to remove it?
    >
    >> libdld.so.1 reports "B.12.41" dated September 2006.
    >> Wow, I already have HP-UX 12.41!!! ;-)
    >> Ulrich

    >
    > There is no connection between linker versions and HP-UX numbering.


  4. Re: Q: return value of lseek64(fd, 0ULL, SEEK_END)

    Ulrich Windl wrote:
    > I'm using printf("%llu", lseek64(...)). Should be OK.


    Yes.

    > could it be that
    > SEEK_END fails for a disk device? I'm trying to find out what the seekable
    > range for a specific disk (RAID logical volume) is.


    Try stat64 instead?

  5. Re: Q: return value of lseek64(fd, 0ULL, SEEK_END)

    Dennis Handly writes:

    > Ulrich Windl wrote:
    >> I'm using printf("%llu", lseek64(...)). Should be OK.

    >
    > Yes.
    >
    >> could it be that
    >> SEEK_END fails for a disk device? I'm trying to find out what the seekable
    >> range for a specific disk (RAID logical volume) is.

    >
    > Try stat64 instead?


    The original problem was that a _successful_ lseek64() followed by a read()
    reported an error, while the position for the lseek64() should be valid. To
    double-check, I tried to report the maximum seek position.

    On your suggestion: Won't the size of a device file always be zero, whatever
    large the connected disk is?

    Regards,
    Ulrich

  6. Re: Q: return value of lseek64(fd, 0ULL, SEEK_END)

    Ulrich Windl wrote:
    > Won't the size of a device file always be zero, whatever
    > large the connected disk is?


    I would assume that is the wrong way to implement things. It should be
    the full size of the disk.

    If what you say is true, you can't use that to check lseek64.

  7. Re: Q: return value of lseek64(fd, 0ULL, SEEK_END)

    Hi!

    I was working on an utility for EFI GUID Partition Tables (GPT) on HP-UX 11.31
    on an rx2620 (After the GPT had been completely lost during recovery attempts;
    something about which HP says it cannot happen...). The machine has a SCSI
    smart array controller...

    The program I wrote tries to read the primary and backup GPT
    Header. Unfortunately it always failed to read the backup GPT Header which
    resides on the last block of the disk ("Invalid Argument), but the program
    could read all other blocks without a problem...

    As the same program on another machine (rx3600 with an SAS RAID controller)
    had no problems reading the last sector of the disk, I started to wonder
    whether the OS or the hardware has a problem doing so.

    Surprisingly I found out that HP's "idisk" always used the raw device
    (/dev/rdisk/...), while I was using the normal device (/dev/disk/...). Now
    using the raw device also, my program can also read the last sector of the
    disk.

    (Linux (SLES10 SP1 for IA64)' parted also had trouble reading the GPT that
    HP-UX created, but I don't know the bugs GNU parted has)

    Can someone explain?

    (The program I wrote is still work in progress, but I can read the GPT
    according to UEFI specifications, and it can print the values (MHO) in a more
    useful way than HP's idisk does. The program also does some consistency checks
    on MBR, GPT header, and GPT Array Entries. I'm planning to add a feature that
    allows to save (and restore from) the GPT to a file. If anybody is willing to
    add some thoughts on the feature set, he/she is welcome to try a copy. The
    program only opens "the disk file" R/O, and you could also provide a disk
    image residing in a file (if you feel worried about your data). The utility
    had been compiled on HP-UX 11.31 IA64 with HP's gcc. Drop me a line if you
    want to have a look at it...)

    Regards,
    Ulrich

+ Reply to Thread