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 <==

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.

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

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

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

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/

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

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/

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