Inquiry on File

[Pando]

Dear Gurus,

I would like to ask what does the letter "T" stands for in the file permission attribute? Below is the example:
-r-------T 1 daemon daemon 300 Apr 14 04:56 C0d569c2360.reply

Also, i would like to ask, how would i search files in a year basis say for example, i want to search for files for the year 2004?

Max points for all correct answers! Thanks!

[Dennis Handly · Accepted solution]

From ls(1):
T No execute/search by others; set sticky bit on execution

For 2004, you can just grep for 2004:
$ ll ... | grep -w 2004

You can add -R for recursive.

If you want to use find(1), you would have to set up two reference files, one on Dec 31, 2003 and one on Dec 31, 2004 and then:
$ touch 1231235903 jan-file
$ touch 1231235904 dec-file
$ find paths -newer jan-file ! -newer dec-file ! -name dec-file

[Robert-Jan Goossens]

Hi Pando,

Have a look at this thread about the meaning of "sticky bit"

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=103855

# cd /tmp
# touch -mt 0401010000 ref1
# touch -mt 0412312359 ref2
# find /filesystem \( -type f -a -newer /tmp/ref1 -a ! -newer /tmp/ref2 \)|xargs -n 100 ls -l {}

0412312359 ( 04 year, 12 mounth, 31 day, 23 hour, 59 minutes)

Hope this helps,
Robert-Jan

[Steven Schweda]

I'm accustomed to dealing with /BEFORE and
/SINCE, where this problem doesn't arise, so
I see "find -newer" as badly designed, but
why would anyone want to leave a one-minute
hole in the year by specifyng "1231235904" or
"0412312359"? (And even adding ".59" to get
seconds seems like a bad idea to me.)

Assuming that "man find" is accurate (so that
"newer" really means "newer"), and that the
file system keeps date-time to better than
one-second precision, then it would appear
that "find" needs either "-newas" or "-older"
to do this job properly. But, in any case,
I'd specify midnight-to-midnight and not
midnight-to-almost_midnight (or
almost_midnight-to-almost_midnight) and take
my chances with a potential one-instant error
rather than with a one-minute (or one-second)
error. If the time resolution of the file
system is no better than one second, then
"-newer" with yyyy-12-31 23:59:59 should be
good enough, but using plain 23:59 seems like
asking for trouble.

Or am I missing something obvious (again)?

[john korterman]

Hi,

....and a diplomatic compromise for finding the files whose last change of content was registered in 2004:

$ find . -type f -exec ls -l {} \;| awk '$8~/2004/{print $9}'

regards,
John K.

[Dennis Handly]

>Steven: And even adding ".59" to get seconds seems like a bad idea to me.)

Ah, right.  "touch -t" is needed, see JRF's post below.

>Assuming that "man find" is accurate (so that "newer" really means "newer"),

Yes, I found my dec file but not jan.

>that the file system keeps date-time to better than one-second precision

No, only seconds.

[Hein van den Heuvel]

Steven >> Or am I missing something obvious (again)?

Yes, your are obviously missing VMS with where (most) utilities use a common set of file selection funtions (such as the / BEFORE and /SINCE mentioned). Where files have creation dates, and where date&time stamps are recorded in sub-second precision and where the system and thus dates are designed to last well beyond 2038.

Now if VMS could only do a FORK properly...

Cheers,
Hein.

[James R. Ferguson]

Hi Pando:

In keeping with the philosophy that there's always more than one way to do something, here's a Perl solution to find (recursively) all files in a directory whose last modification year matches your specification:

# perl -MFile::Find -le 'find(sub{print $File::Find::name if -f && ((localtime((stat)[9]))[5])==$ARGV[0]-1900},".")' 2004

In general, 'cd' to the diretory of interest and pass the year for which you want to find files.

Regards!

...JRF...

[Steven Schweda]

> No, only seconds.

Ok, fine. I suppose that a limitation like
that makes the "find" feature shortage more
tolerable. (I hear that it's also possible
to lean one drunk up against another drunk,
and get a configuration more stable than
either drunk trying to stand by himself.)

But 23:59 is still lame.

> Yes, your are obviously missing VMS [...]

It shows, doesn't it.

[James R. Ferguson]

Hi (again):

Steven > But 23:59 is still lame

OK, I'll agree with that part, but the precision can easily be expanded to one-second resolution. As noted, the smallest granular resolution that stat() offers is in epoch seconds. The use of two reference times with 'find' can accommodate this (see the manpages for 'touch(1)').

# touch -mt 200312312359.59 /tmp/ref1
# touch -mt 200501010000.00 /tmp/ref2
# find . -type f -newer /tmp/ref1 -a ! -newer /tmp/ref2

...offers Pando the ability to find any file modified in the year 2004.

The Perl solution I suggested also adapts the maxiumum one-second resolution. Take your choice. Both are limited to the underlying granularity of the 'stat' structure (see the manpages for stat(5)).

Regards!

...JRF...

[Sandman!]

See ls(1) and chmod(2) for the sticky bit and try the awk to find all 2004 files:

# find / -type f -exec ll + | awk '$8=2004'

~hope it helps

[James R. Ferguson]

Hi (again):

Sandman's solution needs to escape the "+" character since it is special to the shell. Otherwise, the 'find' is correct as written. Thus:

# find / -type f -exec ll \+ | awk '$8=2004'

For the specific question asked, this works well. Using this technique for finding files in year N-1 where the current year is N will not always yield accurate results. For instance, in April 2007, when the time of last modification is less than six months ago as are October, November and December 2006, using 2006 as the 'awk' argument will *miss* file last modified in those months. This, of course, is the standard way 'ls' reports timestamps.

Regards!

...JRF...

[Pando]

Dear Gurus,

Thanks for that wonderful insight! I am just curious, are the file with sticky bit safe to remove? :-(

Thanks!

[Sandman!]

The sticky bit is meaningful only for executable files. No harm removing them as long you have valid backups in case the users suddenly find their apps no longer working.

[Dennis Handly]

>JRF: Sandman's solution needs to escape the "+" character since it is special to the shell.

Which shell treats "+" special??

[James R. Ferguson]

Hi (again):

Dennis > JRF: Sandman's solution needs to escape the "+" character since it is special to the shell. Which shell treats "+" special??

OK, this is interesting. If you examine the 'find(1)' manpages (either for 11.11, 11.23 or 11.31) they note under the discussion of '-exec cmd':

/* begin quote */

The end of cmd must be punctuated by a semicolon (;) or a plus sign (+) (semicolon and plus are special to the shell and must be escaped).

/* end quote */

I will agree, however, that the absence of the escape character doesn't seem to matter. Perhaps I tend to be very sensitive to regular expresssion quantifiers ;-)

Regards!

...JRF...

[Dennis Handly]

>JRF: I will agree, however, that the absence of the escape character doesn't seem to matter.

The last time I asked this question, I postulated it could be due to context dependent files, which were removed with diskless workstations. But the main thing is that you don't know more about this than I do. ;-)

[James R. Ferguson]

HI:

Dennis: But the main thing is that you don't know more about this than I do. ;-)

Excuse me, I'm missing something. Please enlighten me as to how I should interpret that. Given that you work for HP and have access to internals that the rest of us folks don't, I would assume that is a given. Perhaps you would clarify your remark.

...JRF...

[Dennis Handly]

>JRF: Please enlighten me as to how I should interpret that.

The fact you don't have an existence proof other than the man page. An existence proof trumps hand waving and lack of an example. ;-)
I'm assuming there might be a reason for that man page entry, perhaps a different shell. Other than they just copied the ";" case.

[Patrick Wallek]

Dennis,

I think you need to take a few chill pills!

You said: "The fact you don't have an existence proof other than the man page. An existence proof trumps hand waving and lack of an example. ;-)"

OK, so WHAT "existence proof" do you have? Perhaps you would be so kind as to share?

I would ask what we are supposed to go by other than man pages and documentation? That is all us non-HP types have access to. If the man pages are incorrect perhaps you should do something about it other than berating a Forums member that is quite knowledgeable and rather well respected.

[Patrick Wallek]

Dennis,

Oh, and another quote from you: "But the main thing is that you don't know more about this than I do. ;-)"

That is completely uncalled for. If you are going to make statements like that, why not back them up with some substance. From what I have seen, you claim to know more, but have yet to prove it.

[Hein van den Heuvel]

Let's just assume the remark was an unfortunately phrased tease an move on.

In the worst case, it is probably just a mild case of Laurel envy.

those will pass eventually, even when left untreated.

fwiw,

- just because someone lists the ITRC forum company as HP, does not garantuee that is actually the case. Allthough I'm sure Dennis is.

- just because someone works for HP does not mean that person has anything to do with HPUX. Allthough I sure Dennis does.

- just because someone works with hpux, or even for an hpux groups, does not mean they have access to the sources.

- If someone works for HP and posts in an public forum indicating working for HP, then they'd better darn well behave really nicely.

- teases and jokes in public forums are readily and often misinterpreted. Some folks choose to sprinkle them liberaly with smileys but that does nto always cut it, and is annoying in it's own away.

Cheers,
Hein.

[Dennis Handly]

>Patrick: I think you need to take a few chill pills!

I think you misunderstood what I was trying to say. I was basically saying that the man page was wrong in my experience with shells. I was asking JRF if he had any experience to back up the man page. He confessed he didn't. That's all.

>so WHAT "existence proof" do you have?

I don't have any that backs up the man page.

>I would ask what we are supposed to go by other than man pages and documentation?

Actual experience? Reading each shell's documentation?

>If the man pages are incorrect perhaps you should do something about it other than berating a Forums member

Where do you get "berating"? I was just asking if he had proof? I remember replying before (perhaps not to JRF) that it was in the man page but I didn't know why.

Ok, I filed CR JAGag38003 to get find(1) fixed.

>That is completely uncalled for.

This statement simply means, both JRF and I know the same amount about the issue. The smiley was for people who thought I meant more.

>Hein: Let's just assume the remark was an unfortunately phrased tease

Sorry, that wasn't the intention. The intention was to ask if JRF had actual experience backing up the man page.

>does not mean they have access to the sources.

I do but it isn't helpful. It won't do much good to look for something that is just documented wrong.

About the only thing I found in find(1) is that "+" is part of UNIX2003. And that says the only way you can use "+" is by:
$ find ... -exec ... {} +
(You have to have "{}" before the "+". This is only enabled with UNIX_STD=2003, fortunately. This is stated on the 11.31 man page.)

I doubt looking at the sources to sh, ksh and csh would be at all helpful, especially when they don't have any issues with "+".

[James R. Ferguson]

Hi Dennis:

Thank you for the lengthy clarification. I really appreciate it.

I was perplexed and lulled into believing the manpages since they were consistent for three 11i versions and in fact get better (in my opinion) with each successive release.

Sandman is very rigorous in his solutions and I should have tested his code to see that it was indeed sound. Ironically, I wasn't aware that the curly braces before the plus character are optional (UNIX 2003 aside as you to mentioned) _until_ I consulted the manpages for that, so I learned a bit from Sandman's post from that perspective too.

Reviewing the shell manpages again leaves one wondering about the admonishment in the 'find' documentation.

Thank you very much for filing a fix.

There are no hard feeling on my part nor I hope on anyone else's.

Regards!

...JRF...