file creation date - SCO

This is a discussion on file creation date - SCO ; Is there any way to display the file creation date? Thank you Smokey...

+ Reply to Thread
Results 1 to 10 of 10

Thread: file creation date

  1. file creation date

    Is there any way to display the file creation date?

    Thank you

    Smokey

  2. Re: file creation date

    oldsmokee@yahoo.com typed (on Fri, May 25, 2007 at 02:27:59PM -0500):
    | Is there any way to display the file creation date?

    Nothing in Unix records the date a file was created.

    --
    JP
    ==> http://www.frappr.com/cusm <==

  3. Re: file creation date

    I found cr_time in htino.h along with c_time, a_time, and m_time.
    Supposedly cr_time is the creation time. Is this not implemented or
    maybe htino.h is not used for the sco unix inode structure?

    Smokeyh


    On Fri, 25 May 2007 15:49:07 -0400, Jean-Pierre Radley
    wrote:

    >oldsmokee@yahoo.com typed (on Fri, May 25, 2007 at 02:27:59PM -0500):
    >| Is there any way to display the file creation date?
    >
    >Nothing in Unix records the date a file was created.


  4. Re: file creation date

    On Fri, May 25, 2007, oldsmokee@yahoo.com wrote:
    >I found cr_time in htino.h along with c_time, a_time, and m_time.
    >Supposedly cr_time is the creation time. Is this not implemented or
    >maybe htino.h is not used for the sco unix inode structure?


    If you look at the man pages for the stat() command, you will see
    there are only three members of sturct stat relating to time,
    st_atime, st_mtime, and st_ctime.

    st_atime = time of last access
    st_mtime = time of last modification
    st_ctime = time of last status change (which includes chmod).

    The st_atime and st_mtime values may be changed with the utime
    command, but the st_ctime is maintained by the system and not
    under general program control.

    I'm reasonably sure that this is a POSIX standard, not particular
    to Unix as implemented by SCO (who owns it is a matter of some
    litigation now :-).

    Bill
    --
    INTERNET: bill@Celestial.COM Bill Campbell; Celestial Software LLC
    URL: http://www.celestial.com/ PO Box 820; 6641 E. Mercer Way
    FAX: (206) 232-9186 Mercer Island, WA 98040-0820; (206) 236-1676

    ``We'll show the world we are prosperous, even if we have to go broke to do
    it.''
    Will Rogers

  5. Re: file creation date

    Thank you.

    The man page for inode refers to
    htino.h | S51K (UNIX filesystem), HTFS
    | (High Throughput Filesystem),
    | EAFS (Enhanced ACER Fast
    | Filesystem) and AFS (ACER Fast
    | Filesystem)
    The htino.h includes

    struct dinode32 { ushort d32_mode; /* mode and
    type of file */ short d32_nlink; /* number of
    links to file */ ulong_t d32_uid; /* owner's
    user id */ ulong_t d32_gid; /* owner's group id
    */ daddr_t d32_addr[NADDR]; /* disk block addresses */
    long d32_gen; /* file generation number */
    time_t d32_atime; /* time last accessed */
    time_t d32_mtime; /* time last modified */
    time_t d32_ctime; /* time status last changed */
    time_t d32_crtime; /* time file was created */
    ulong_t d32_flag; /* see below */
    My questions are now
    Is this structure implemented by SCO?
    If so is the d32_crtime implemented?
    If so how do I get to it?

    Smokey

    On Fri, 25 May 2007 15:13:57 -0700, Bill Campbell
    wrote:

    >On Fri, May 25, 2007, oldsmokee@yahoo.com wrote:
    >>I found cr_time in htino.h along with c_time, a_time, and m_time.
    >>Supposedly cr_time is the creation time. Is this not implemented or
    >>maybe htino.h is not used for the sco unix inode structure?

    >
    >If you look at the man pages for the stat() command, you will see
    >there are only three members of sturct stat relating to time,
    >st_atime, st_mtime, and st_ctime.
    >
    >st_atime = time of last access
    >st_mtime = time of last modification
    >st_ctime = time of last status change (which includes chmod).
    >
    >The st_atime and st_mtime values may be changed with the utime
    >command, but the st_ctime is maintained by the system and not
    >under general program control.
    >
    >I'm reasonably sure that this is a POSIX standard, not particular
    >to Unix as implemented by SCO (who owns it is a matter of some
    >litigation now :-).
    >
    >Bill


  6. Re: file creation date

    In article ,
    wrote:
    >Is there any way to display the file creation date?
    >
    >Thank you
    >
    >Smokey


    The only Unix variant of which I know that supports creation time
    [the ctime was mis-documented as creation time in SCO's Xenix
    manual] is FreeBSD. And in FBSD it is called 'birthtime'.

    This is when they doulbed the inode size in UFS2 from the standard
    inode size used in virtually all other Unix/Unix-like systems.

    Here is about the only place you see it documented - at the moment.

    ---------------------

    #if __BSD_VISIBLE
    struct timespec st_birthtimespec; /* time of file creation */
    /*
    * Explicitly pad st_birthtimespec to 16 bytes so that the size of
    * struct stat is backwards compatible. We use bitfields instead
    * of an array of chars so that this doesn't require a C99 compiler
    * to compile if the size of the padding is 0. We use 2 bitfields
    * to cover up to 64 bits on 32-bit machines. We assume that
    * CHAR_BIT is 8...
    */
    unsigned int 8 / 2) * (16 - (int)sizeof(struct timespec));
    unsigned int 8 / 2) * (16 - (int)sizeof(struct timespec));
    #else
    time_t st_birthtime; /* time of file creation */
    long st_birthtimensec; /* nsec of file creation */
    unsigned int 8 / 2) * (16 - (int)sizeof(struct __timespec));
    unsigned int 8 / 2) * (16 - (int)sizeof(struct __timespec));
    #endif
    };

    ---------------------
    --
    Bill Vermillion - bv @ wjv . com

  7. Re: file creation date

    In article ,
    wrote:
    >The htino.h includes
    >
    >struct dinode32 {
    >ushort d32_mode; /* mode and type of file */
    >short d32_nlink; /* number of links to file */
    >ulong_t d32_uid; /* owner's user id */
    >ulong_t d32_gid; /* owner's group id */
    >daddr_t d32_addr[NADDR]; /* disk block addresses */
    >long d32_gen; /* file generation number */
    >time_t d32_atime; /* time last accessed */
    >time_t d32_mtime; /* time last modified */
    >time_t d32_ctime; /* time status last changed */
    >time_t d32_crtime; /* time file was created */
    >ulong_t d32_flag; /* see below */
    >My questions are now
    >Is this structure implemented by SCO?


    Yes.

    >If so is the d32_crtime implemented?


    Yes.

    >If so how do I get to it?


    With 'crash', if there happens to be an in-core version of the inode.
    In other words - for practical purposes, you don't.
    Since there is no stat member to pass this information out in,
    there's no way for you to access it from user space.

    Why, then, is it implemented? It's used for file versioning; the creation
    time of a file (specifically, its inode allocation time) is one of the
    factors used to determine whether a file should be versioned when it is
    removed/truncated - see 'minvtime' in mount(ADM).

    Sorry!

    John
    --
    John DuBois spcecdt@armory.com KC6QKZ/AE http://www.armory.com/~spcecdt/

  8. Re: file creation date

    Thank you.

    Someone has to be able to access it.??

    If I could program in C could I access it?

    Smokey


    On Sun, 27 May 2007 01:54:50 -0000, spcecdt@armory.com (John DuBois)
    wrote:

    >In article ,
    > wrote:
    >>The htino.h includes
    >>
    >>struct dinode32 {
    >>ushort d32_mode; /* mode and type of file */
    >>short d32_nlink; /* number of links to file */
    >>ulong_t d32_uid; /* owner's user id */
    >>ulong_t d32_gid; /* owner's group id */
    >>daddr_t d32_addr[NADDR]; /* disk block addresses */
    >>long d32_gen; /* file generation number */
    >>time_t d32_atime; /* time last accessed */
    >>time_t d32_mtime; /* time last modified */
    >>time_t d32_ctime; /* time status last changed */
    >>time_t d32_crtime; /* time file was created */
    >>ulong_t d32_flag; /* see below */
    >>My questions are now
    >>Is this structure implemented by SCO?

    >
    >Yes.
    >
    >>If so is the d32_crtime implemented?

    >
    >Yes.
    >
    >>If so how do I get to it?

    >
    >With 'crash', if there happens to be an in-core version of the inode.
    >In other words - for practical purposes, you don't.
    >Since there is no stat member to pass this information out in,
    >there's no way for you to access it from user space.
    >
    >Why, then, is it implemented? It's used for file versioning; the creation
    >time of a file (specifically, its inode allocation time) is one of the
    >factors used to determine whether a file should be versioned when it is
    >removed/truncated - see 'minvtime' in mount(ADM).
    >
    >Sorry!
    >
    > John


  9. Re: file creation date

    In article ,
    wrote:
    >Thank you.
    >
    >Someone has to be able to access it.??


    Not at the user-space filesystem API level.
    It's used exclusively within the kernel.

    >If I could program in C could I access it?


    You would need to operate on the filesystem device, like fsdb/clri/quot/etc.
    do. Not very nice. It would involve using stat to get the device and inode
    number of a file, searching through /dev to convert the device number to a
    filesystem device name, checking that the device contains an HTFS filesystem,
    calculating the offset in that device of the inode that contains the file,
    reading that inode (in block mode), and extracting the creation time from it.

    If you aren't concerned with efficiency, you could use fsdb, which knows about
    the filesystem format. A demonstration of concept, lacking error checking,
    any attempt at efficiency, and such:

    #!/bin/sh
    for name
    do
    set -- `ls -id -- "$name"`
    inum=$1
    set -- `devnm -- "$name"`
    device=$1
    echo ${inum}i.mt+2 | fsdb "$device" | gawk -F'[()]' '
    NR == 3 { printf "%s ", strftime("%F %T", $2) }'
    echo "$name"
    done

    This uses the fact that though fsdb doesn't know about the creation time
    element, it does know where the mtime element is in the inode, and the crtime
    element is the second element after that.

    Note that the creation time is of course not maintained by any sort of copying,
    or even moving a file between filesystems - if an operation involves allocating
    a new inode, the creation time is set to the current time.

    John

    >On Sun, 27 May 2007 01:54:50 -0000, spcecdt@armory.com (John DuBois)
    >wrote:
    >
    >>In article ,
    >> wrote:
    >>>The htino.h includes
    >>>
    >>>struct dinode32 {
    >>>ushort d32_mode; /* mode and type of file */
    >>>short d32_nlink; /* number of links to file */
    >>>ulong_t d32_uid; /* owner's user id */
    >>>ulong_t d32_gid; /* owner's group id */
    >>>daddr_t d32_addr[NADDR]; /* disk block addresses */
    >>>long d32_gen; /* file generation number */
    >>>time_t d32_atime; /* time last accessed */
    >>>time_t d32_mtime; /* time last modified */
    >>>time_t d32_ctime; /* time status last changed */
    >>>time_t d32_crtime; /* time file was created */
    >>>ulong_t d32_flag; /* see below */
    >>>My questions are now
    >>>Is this structure implemented by SCO?

    >>
    >>Yes.
    >>
    >>>If so is the d32_crtime implemented?

    >>
    >>Yes.
    >>
    >>>If so how do I get to it?

    >>
    >>With 'crash', if there happens to be an in-core version of the inode.
    >>In other words - for practical purposes, you don't.
    >>Since there is no stat member to pass this information out in,
    >>there's no way for you to access it from user space.
    >>
    >>Why, then, is it implemented? It's used for file versioning; the creation
    >>time of a file (specifically, its inode allocation time) is one of the
    >>factors used to determine whether a file should be versioned when it is
    >>removed/truncated - see 'minvtime' in mount(ADM).
    >>
    >>Sorry!
    >>
    >> John



    --
    John DuBois spcecdt@armory.com KC6QKZ/AE http://www.armory.com/~spcecdt/

  10. Re: file creation date

    I already know the inode number and the device number.
    I am going to study the script and the fsdb man pages etc.
    The reason I want to find the creation date is because a
    file was removed and recreated. I would like to know when
    it was recreated to try to pin down who was around to rm it.

    I know but the sys admin turned off all accounting because the
    files were getting to big.

    Smokey

    p.s. great looking kids. I have 2 girls and a boy. The girls are 40
    and the boy just turned 30.

    On Mon, 28 May 2007 02:50:19 -0000, spcecdt@armory.com (John DuBois)
    wrote:

    >In article ,
    > wrote:
    >>Thank you.
    >>
    >>Someone has to be able to access it.??

    >
    >Not at the user-space filesystem API level.
    >It's used exclusively within the kernel.
    >
    >>If I could program in C could I access it?

    >
    >You would need to operate on the filesystem device, like fsdb/clri/quot/etc.
    >do. Not very nice. It would involve using stat to get the device and inode
    >number of a file, searching through /dev to convert the device number to a
    >filesystem device name, checking that the device contains an HTFS filesystem,
    >calculating the offset in that device of the inode that contains the file,
    >reading that inode (in block mode), and extracting the creation time from it.
    >
    >If you aren't concerned with efficiency, you could use fsdb, which knows about
    >the filesystem format. A demonstration of concept, lacking error checking,
    >any attempt at efficiency, and such:
    >
    >#!/bin/sh
    >for name
    >do
    > set -- `ls -id -- "$name"`
    > inum=$1
    > set -- `devnm -- "$name"`
    > device=$1
    > echo ${inum}i.mt+2 | fsdb "$device" | gawk -F'[()]' '
    > NR == 3 { printf "%s ", strftime("%F %T", $2) }'
    > echo "$name"
    >done
    >
    >This uses the fact that though fsdb doesn't know about the creation time
    >element, it does know where the mtime element is in the inode, and the crtime
    >element is the second element after that.
    >
    >Note that the creation time is of course not maintained by any sort of copying,
    >or even moving a file between filesystems - if an operation involves allocating
    >a new inode, the creation time is set to the current time.
    >
    > John
    >
    >>On Sun, 27 May 2007 01:54:50 -0000, spcecdt@armory.com (John DuBois)
    >>wrote:
    >>
    >>>In article ,
    >>> wrote:
    >>>>The htino.h includes
    >>>>
    >>>>struct dinode32 {
    >>>>ushort d32_mode; /* mode and type of file */
    >>>>short d32_nlink; /* number of links to file */
    >>>>ulong_t d32_uid; /* owner's user id */
    >>>>ulong_t d32_gid; /* owner's group id */
    >>>>daddr_t d32_addr[NADDR]; /* disk block addresses */
    >>>>long d32_gen; /* file generation number */
    >>>>time_t d32_atime; /* time last accessed */
    >>>>time_t d32_mtime; /* time last modified */
    >>>>time_t d32_ctime; /* time status last changed */
    >>>>time_t d32_crtime; /* time file was created */
    >>>>ulong_t d32_flag; /* see below */
    >>>>My questions are now
    >>>>Is this structure implemented by SCO?
    >>>
    >>>Yes.
    >>>
    >>>>If so is the d32_crtime implemented?
    >>>
    >>>Yes.
    >>>
    >>>>If so how do I get to it?
    >>>
    >>>With 'crash', if there happens to be an in-core version of the inode.
    >>>In other words - for practical purposes, you don't.
    >>>Since there is no stat member to pass this information out in,
    >>>there's no way for you to access it from user space.
    >>>
    >>>Why, then, is it implemented? It's used for file versioning; the creation
    >>>time of a file (specifically, its inode allocation time) is one of the
    >>>factors used to determine whether a file should be versioned when it is
    >>>removed/truncated - see 'minvtime' in mount(ADM).
    >>>
    >>>Sorry!
    >>>
    >>> John


+ Reply to Thread