Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] SSL over Unix-domain sockets

From: Greg Smith <gsmith(at)gregsmith(dot)com>
To: PostgreSQL-patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: [HACKERS] SSL over Unix-domain sockets
Date: 2008-01-18 08:37:00
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-patches
On Thu, 17 Jan 2008, Tom Lane wrote:

> BTW, is a symlink's atime changed by accessing it?

It seems so in the cases I've tried or researched, but it's complicated. 
After burning through a bunch of time looking into this I wanted to drop 
some notes so nobody else has to wander down the specific dead-ends I just 

I figured I'd just run some experiments to figure this out for my Linux 
system, but that didn't go so well.  The process of running anything that 
shows the atime:

   ls -l --time=atime <file>
   ls -lu <file>
   stat <file>

actually updates the atime to right now along the way.  I hacked up 
something with perl that directly calls lstat() and it did the same thing.

Mystified, I found this thread suggesting the same thing is true on Mac OS 

The point made in there is that how symlinks are encoded varies not just 
from OS to OS but from filesystem to filesystem, and that encoding changes 
how things like atime work.  On Linux with ext2, I found this note:

"Symbolic links are also filesystem objects with inodes.  They deserve 
special mention because the data for them is stored within the inode 
itself if the symlink is less than 60 bytes long.  It uses the fields 
which would normally be used to store the pointers to data blocks."

So what I think is happening is:  the process of doing anything at all 
with a Linux symlink references the inode that has the link.  That updates 
the atime on that inode.  But since there's no actual data underneath that 
lookup in cases where the link is less than 60 bytes, the inode atime is 
the link atime, so that just updated the link's atime to right now as 
well.  I have no idea how any tmp cleaner could ever find a short symlink 
it can delete if I'm understanding this correctly.

I left behind the link I was just playing with and I'll see if I can get 
tmpwatch to eat it tomorrow, that seems like the most appropriate test 

* Greg Smith gsmith(at)gregsmith(dot)com Baltimore, MD

In response to

pgsql-hackers by date

Next:From: Dave PageDate: 2008-01-18 09:17:13
Subject: Re: Simple thing to make pg_autovacuum more useful
Previous:From: Magnus HaganderDate: 2008-01-18 08:23:26
Subject: Re: Simple thing to make pg_autovacuum more useful

pgsql-patches by date

Next:From: Peter EisentrautDate: 2008-01-18 10:22:41
Subject: Re: [HACKERS] SSL over Unix-domain sockets
Previous:From: Stefan SchwarzerDate: 2008-01-18 06:00:52
Subject: Re: Forgot to dump old data before re-installing machine

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group