0

on my xubuntu 19.10-amd64 system I have cron running backup jobs every midnight. The destination directories created by the rsync command should therefore have timestamps of 00:00. However I'm seeing weirdness in the timestamps.
tcsh (my preferred interactive shell) correctly shows timestamps of 00:00 on successive days, but bash and /bin/sh both list all the destination directories with timestamps of the incorrect date and time (see screen capture). Because the timestamps are identical, "ls -lt" ordering is arbitrary (i.e. wrong) in the /bin/sh script, and my script fails to find the "oldest" backup. Both source and destination are on local ext4 filestems (local SSD to local HDD); there is no nfs involved and no remote system. If I manually "touch" one of the destination folders, both bash and tcsh report the new timestamp. I can't find any prior discussion of different shells reporting differing timestamps. Any advice on where should I look for help troubleshooting this? thanks...

dean/ 101 >tcsh
dean/ 89 >ls -ltd /mnt/HDD4/Backups/CUDA1.home.0.*
drwxr-xr-x 4 root root 4096 Nov 18 00:00 /mnt/HDD4/Backups/CUDA1.home.0.2019-11-18/
drwxr-xr-x 4 root root 4096 Nov 17 00:00 /mnt/HDD4/Backups/CUDA1.home.0.2019-11-17/
drwxr-xr-x 4 root root 4096 Nov 16 00:00 /mnt/HDD4/Backups/CUDA1.home.0.2019-11-16/
dean/ 90 >bash
dean@CUDA1:~$ ls -ltd /mnt/HDD4/Backups/CUDA1.home.0.*
drwxr-xr-x 4 root root 4096 Nov 14 16:31 /mnt/HDD4/Backups/CUDA1.home.0.2019-11-16
drwxr-xr-x 4 root root 4096 Nov 14 16:31 /mnt/HDD4/Backups/CUDA1.home.0.2019-11-17
drwxr-xr-x 4 root root 4096 Nov 14 16:31 /mnt/HDD4/Backups/CUDA1.home.0.2019-11-18
dean@CUDA1:~$ sudo touch /mnt/HDD4/Backups/CUDA1.home.0.2019-11-18
[sudo] password for dean: 
dean@CUDA1:~$ !ls
ls -ltd /mnt/HDD4/Backups/CUDA1.home.0.*
drwxr-xr-x 4 root root 4096 Nov 18 12:52 /mnt/HDD4/Backups/CUDA1.home.0.2019-11-18
drwxr-xr-x 4 root root 4096 Nov 14 16:31 /mnt/HDD4/Backups/CUDA1.home.0.2019-11-16
drwxr-xr-x 4 root root 4096 Nov 14 16:31 /mnt/HDD4/Backups/CUDA1.home.0.2019-11-17
dean@CUDA1:~$ exit
exit
dean/ 91 >!ls
ls -ltd /mnt/HDD4/Backups/CUDA1.home.0.*
drwxr-xr-x 4 root root 4096 Nov 18 12:52 /mnt/HDD4/Backups/CUDA1.home.0.2019-11-18/
drwxr-xr-x 4 root root 4096 Nov 17 00:00 /mnt/HDD4/Backups/CUDA1.home.0.2019-11-17/
drwxr-xr-x 4 root root 4096 Nov 16 00:00 /mnt/HDD4/Backups/CUDA1.home.0.2019-11-16/
  • Is ls aliased in either interactive shell (to ls -u for example)? – steeldriver Nov 18 '19 at 22:02
  • oh good point I hadn't thought of that... yup that was it. both shells had "ls" aliased to different things. I'll write it up as the answer and accept it. thanks. – user3071462 Nov 18 '19 at 22:24
0

per steeldriveer's comment, both shells inherited different aliases for "ls". Explicitly executing /bin/ls gives consistent results. solved. Thanks.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.