- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - Linux
- >
- Inquiry on File
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Forums
Discussions
Discussions
Discussions
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-13-2007 08:16 PM
04-13-2007 08:16 PM
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!
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-13-2007 09:28 PM
04-13-2007 09:28 PM
SolutionT 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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-13-2007 09:41 PM
04-13-2007 09:41 PM
Re: Inquiry on File
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-13-2007 10:30 PM
04-13-2007 10:30 PM
Re: Inquiry on File
/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)?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-13-2007 11:32 PM
04-13-2007 11:32 PM
Re: Inquiry on File
....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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-14-2007 12:09 AM - edited 10-06-2011 04:11 PM
04-14-2007 12:09 AM - edited 10-06-2011 04:11 PM
Re: Inquiry on File
>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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-14-2007 01:15 AM
04-14-2007 01:15 AM
Re: Inquiry on File
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-14-2007 03:34 AM
04-14-2007 03:34 AM
Re: Inquiry on File
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...
- Tags:
- Perl
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-14-2007 05:27 AM
04-14-2007 05:27 AM
Re: Inquiry on File
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-14-2007 06:25 AM
04-14-2007 06:25 AM
Re: Inquiry on File
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...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-14-2007 08:16 AM
04-14-2007 08:16 AM
Re: Inquiry on File
# find / -type f -exec ll + | awk '$8=2004'
~hope it helps
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-14-2007 01:41 PM
04-14-2007 01:41 PM
Re: Inquiry on File
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...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-15-2007 12:44 PM
04-15-2007 12:44 PM
Re: Inquiry on File
Thanks for that wonderful insight! I am just curious, are the file with sticky bit safe to remove? :-(
Thanks!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-15-2007 02:01 PM
04-15-2007 02:01 PM
Re: Inquiry on File
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-15-2007 07:15 PM
04-15-2007 07:15 PM
Re: Inquiry on File
Which shell treats "+" special??
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-16-2007 12:15 AM
04-16-2007 12:15 AM
Re: Inquiry on File
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...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-16-2007 01:54 PM
04-16-2007 01:54 PM
Re: Inquiry on File
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. ;-)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-16-2007 11:00 PM
04-16-2007 11:00 PM
Re: Inquiry on File
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...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-17-2007 12:22 AM
04-17-2007 12:22 AM
Re: Inquiry on File
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-17-2007 01:16 AM
04-17-2007 01:16 AM
Re: Inquiry on File
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-17-2007 01:20 AM
04-17-2007 01:20 AM
Re: Inquiry on File
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-17-2007 03:24 AM
04-17-2007 03:24 AM
Re: Inquiry on File
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-18-2007 12:22 AM
04-18-2007 12:22 AM
Re: Inquiry on File
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 "+".
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-18-2007 01:30 AM
04-18-2007 01:30 AM
Re: Inquiry on File
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...