1

I'm checking an alternative to 'find' command in shell scripting so as to eliminate the discrepancy of Accessed date of sub directories.

According to my observation, when find command is executed to list all the files in a directory, the accessed date of sub-directories is getting changed.

I want to post genuine statistics in one of the junk platforms, So I have been looking at some forums and got the alternative with 'ls' command. But that doesn't completely fulfill my request.

Below is the answer given by @ghostdog74. 

ls -R %path% | awk '/:$/&&f{s=$0;f=0} /:$/&&!f{sub(/:$/,"");s=$0;f=1;next} NF&&f{ print s"/"$0 }'.

But this finds only the files inside the sub directories. I need all the files and sub-directories' files to be listed.

For example:

bash-3.2# pwd

/Users/manojkapalavai/Desktop/SleepTimeReport

bash-3.2# ls

**6th floor**   manoj17     manoj26.txt manoj36     manoj45.txt manoj55             manoj70.txt manoj80     manoj9.txt  **test1**
manoj14     manoj23.txt manoj33     manoj42.txt manoj52     manoj61.txt manoj71     manoj80.txt manoj90     **test2**.

The highlighted ones are sub-directories inside "SleepTimeReport" directory and remaining are just files. So, when I execute the above command, I get only the below output. 

bash-3.2# ls -R ~/Desktop/SleepTimeReport | awk '/:$/&&f{s=$0;f=0} /:$/&&!f{sub(/:$/,"");s=$0;f=1;next} NF&&f{ print s"/"$0 }'. 

~/Desktop/SleepTimeReport/6th floor/Script to increase the Sleep Time.numbers. 
~/Desktop/SleepTimeReport/6th floor/Zone1Sleep.pages. 
~/Desktop/SleepTimeReport/test1/New_folder. 
~/Desktop/SleepTimeReport/test1/manoj.txt. 
~/Desktop/SleepTimeReport/test1/sathish.txt. 
~/Desktop/SleepTimeReport/test1/vara.txt. 
~/Desktop/SleepTimeReport/test1/New_folder/Script to increase the Sleep Time.numbers. 
~/Desktop/SleepTimeReport/test1/New_folder/Zone1Sleep.pages.

i.e.; only those files inside sub-directories are listed.

Brief explanation of what issue I'm facing, please see below

Manojs-MacBook-Pro:SleepTimeReport manojkapalavai$ ls -l
total 16
drwxr-xr-x   8 manojkapalavai  staff  272 Sep 14 15:07 6th floor
-rwxr-xr-x   1 manojkapalavai  staff   59 Nov 13 10:41 AltrFind.sh
-rw-r--r--   1 manojkapalavai  staff    0 Nov  2 15:15 manoj%.txt
-rw-r--r--   1 manojkapalavai  staff    0 Nov  2 18:23 manoj1

When I try finding Created time and Accessed Time of the folder 6th floor before using 'find' command, the below is output.

Manojs-MacBook-Pro:SleepTimeReport manojkapalavai$ stat -f '%N, %SB, %Sa' 6th\ floor/
6th floor/, Sep 13 10:34:55 2017, **Nov 13 11:21:33 2017**

Manojs-MacBook-Pro:SleepTimeReport manojkapalavai$ find /Users/manojkapalavai/Desktop/SleepTimeReport/
/Users/manojkapalavai/Desktop/SleepTimeReport/
/Users/manojkapalavai/Desktop/SleepTimeReport//6th floor
/Users/manojkapalavai/Desktop/SleepTimeReport//6th floor/.DS_Store
/Users/manojkapalavai/Desktop/SleepTimeReport//6th floor/Script to increase the Sleep Time.numbers
/Users/manojkapalavai/Desktop/SleepTimeReport//6th floor/Zone1Sleep.pages

Now, after finding all the files inside a directory, below is the output of atime. you can notice the change

Manojs-MacBook-Pro:SleepTimeReport manojkapalavai$ stat -f '%N, %SB, %Sa' 6th\ floor/
6th floor/, Sep 13 10:34:55 2017, **Nov 13 14:26:03 2017**

All tha I have done is just find the files, and atime of sub-folders inside a folder when we find is getting changed to that current time.

Is there any way to solve this?

Charles Duffy
  • 280,126
  • 43
  • 390
  • 441
Manoj Kapalavai
  • 11
  • 3
  • What is your observation for that `find` changes access time of sub dirs? – thanasisp Nov 10 '17 at 13:00
  • 3
    @ManojKapalavai : Unless you are doing something nasty in the `-exec` clause of find, the dates are not modified - with one exception: If your environment is Cygwin and you are on Windows 7 or higher, it can happen that the file modification date is changed, even if you never read the file. This weird behaviour is dependent on a certain registry setting of Windows and is not related to the `find` command. – user1934428 Nov 10 '17 at 14:37
  • @thanasisp, I'm using find command for listing the files and piping with stat to find out statistics of all the files. In this scenario, the statistics of sub-directories present seems to be in trouble (particularly Accessed Date). I found Accessed date is getting updated as on when 'find' is happening on that. – Manoj Kapalavai Nov 13 '17 at 06:00
  • I tried `mkdir 1; mkdir 1/2` and after a minute `find . -type d; ls -lu` and i see there was no modification in atime of `./1`. this is why i asked. Please check comment above. – thanasisp Nov 13 '17 at 07:28
  • @thanasisp ok, but check the same when you have some files inside that directory. If its a empty directory atime doesn't change, but if the directory contains some files, atime is changing – Manoj Kapalavai Nov 13 '17 at 09:48
  • I do not reproduce what you say for my OS/filesystem/find – thanasisp Nov 13 '17 at 10:13

1 Answers1

1

ls is the wrong tool for programmatic use. Generally, you should be able to fix your find usage to not have an effect on atimes (actually, it's pretty rare for folks to even have atimes enabled at the filesystem level on modern production systems), but if you really want to avoid it, consider the bash globstar option:

shopt -s globstar
for file in **/*; do
  echo "Doing whatever with $file"
done
Charles Duffy
  • 280,126
  • 43
  • 390
  • 441
  • Thanks Charles, but **shopt** is also changing the accessed date of the directories. The main point is to find out the genuine accessed dates of the sub-directories after listing all the files and sub-directories inside a directory. Any help? – Manoj Kapalavai Nov 13 '17 at 06:01
  • @ManojKapalavai, what's your filesystem, and what are the mount options / flags used with it? If it considers any listing to be an access, then it won't be possible to fix this with any tools whatsoever (ie. `ls -R` will have the same problem, as would anything you wrote yourself in C, etc). – Charles Duffy Nov 13 '17 at 15:43
  • @ManojKapalavai, ...or, rather, not possible **without changing your filesystem or mount flags**. Which is to say, you need to bring those things into the scope of the question. – Charles Duffy Nov 13 '17 at 15:50