Asp Forum - File.ctime for detecting directory modifications?

e

9/1/2006 11:09:00 PM

Hi!

Can anyone tell me if Ruby's File.ctime can be reliably
used to detect if a directory's contents have changed?

I do not need to know of changes to files, just adds and
deletes of files to/from the directory itself.

I have tested this on FreeBSD and OpenBSD and both seem
to indicate my expected behaviour (although File.mtime
does not)--if anyone can try other platforms or knows
offhand, the information would be appreciated. Windows
is not a concern.

In case you are curious, I intend to cache the files under
$PATH and only re-access them if a modification has been
detected. Alternative solutions to this are also welcome.

--
Posted via http://www.ruby-....

10 Answers

Paul Lutus

9/2/2006 12:41:00 AM

Eero Saynatkari wrote:

> Hi!
>
> Can anyone tell me if Ruby's File.ctime can be reliably
> used to detect if a directory's contents have changed?
>
> I do not need to know of changes to files, just adds and
> deletes of files to/from the directory itself.

On Linux, File.ctime(path) can be used on a directory to detect file
additions or removals, but not changes to existing files.

Example code:

#!/usr/bin/ruby

path="/temp2"

ot = File.ctime(path)

while true
nt = File.ctime(path)
puts "#{path} changed at #{Time.new}" if nt != ot
ot = nt
sleep 1
end

> In case you are curious, I intend to cache the files under
> $PATH and only re-access them if a modification has been
> detected.

Okay, now you are saying "modification", not addition or removal. On Linux,
File.ctime won't flag change in the directory when file contents change,
only additions or removals.

BTW File.mtime and File.ctime appear to act the same under Linux.

> Alternative solutions to this are also welcome.

You want to monitor a directory of files for changes and act if one or more
of them has changed, yes? Why not simply collect stats on all the files
periodically, and compare new times with old for each file?

--
Paul Lutus
http://www.ara...

e

9/2/2006 1:00:00 AM

Paul Lutus wrote:
> Eero Saynatkari wrote:
>
>> Hi!
>>
>> Can anyone tell me if Ruby's File.ctime can be reliably
>> used to detect if a directory's contents have changed?
>>
>> I do not need to know of changes to files, just adds and
>> deletes of files to/from the directory itself.
>
> On Linux, File.ctime(path) can be used on a directory to detect file
> additions or removals, but not changes to existing files.

Excellent, this is just what I needed to know.

> Example code:
>
> #!/usr/bin/ruby
>
> path="/temp2"
>
> ot = File.ctime(path)
>
> while true
> nt = File.ctime(path)
> puts "#{path} changed at #{Time.new}" if nt != ot
> ot = nt
> sleep 1
> end
>
>> In case you are curious, I intend to cache the files under
>> $PATH and only re-access them if a modification has been
>> detected.
>
> Okay, now you are saying "modification", not addition or removal. On
> Linux,
> File.ctime won't flag change in the directory when file contents change,
> only additions or removals.

No, I am sorry for mixing terms. I needed to monitor additions
and removals which (in my addled brain are modifications of the
directory 'file' itself).

> BTW File.mtime and File.ctime appear to act the same under Linux.
>
>> Alternative solutions to this are also welcome.
>
> You want to monitor a directory of files for changes and act if one or
> more
> of them has changed, yes? Why not simply collect stats on all the files
> periodically, and compare new times with old for each file?

I have to be assured that my cache is up-to-date, so I
check the ctime each time anything in that directory
is invoked--if there has been a change, I re-cache the
directory.

--
Posted via http://www.ruby-....

Paul Lutus

9/2/2006 1:13:00 AM

Eero Saynatkari wrote:

/ ...

> I have to be assured that my cache is up-to-date, so I
> check the ctime each time anything in that directory
> is invoked--if there has been a change, I re-cache the
> directory.

Well, I ran my little program and added and removed files from the target
directory, with a printout on each change, so it appears to work for the
Linux kernel. Many Unices and similar operating systems will behave the
same.

--
Paul Lutus
http://www.ara...

Rick DeNatale

9/2/2006 9:17:00 PM

On 9/1/06, Paul Lutus <nospam@nosite.zzz> wrote:
> Eero Saynatkari wrote:
>
> / ...
>
> > I have to be assured that my cache is up-to-date, so I
> > check the ctime each time anything in that directory
> > is invoked--if there has been a change, I re-cache the
> > directory.
>
> Well, I ran my little program and added and removed files from the target
> directory, with a printout on each change, so it appears to work for the
> Linux kernel. Many Unices and similar operating systems will behave the
> same.

Actually, won't this behavior depend on the file system rather than the kernel?

I don't know about ctime, but some filesystems allow control over
whether other attributed like atime are maintained or updated.

--
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denh...

Paul Lutus

9/2/2006 11:45:00 PM

Rick DeNatale wrote:

/ ...

> Actually, won't this behavior depend on the file system rather than the
> kernel?
>
> I don't know about ctime, but some filesystems allow control over
> whether other attributed like atime are maintained or updated.

Good question, to which I don't have a general answer. I assumed that the
handling of file times were rather central to the identity of an operating
system (rather than a filesystem). It's just an assumption.

--
Paul Lutus
http://www.ara...

Garance A Drosehn

9/3/2006 1:19:00 AM

On 9/2/06, Paul Lutus <nospam@nosite.zzz> wrote:
> Rick DeNatale wrote:
>
> / ...
>
> > Actually, won't this behavior depend on the file system rather than the
> > kernel?
> >
> > I don't know about ctime, but some filesystems allow control over
> > whether other attributed like atime are maintained or updated.
>
> Good question, to which I don't have a general answer. I assumed that the
> handling of file times were rather central to the identity of an operating
> system (rather than a filesystem). It's just an assumption.

The operating system just reports what the filesystem tells it.
Consider the example where you have a distributed file system.
The computer which is doing the Stat call may not be the same
computer which added some file to the directory. It is only the
information stored in the filesystem itself which can be seen on
both systems.

I expect your trick would work in very many situations, but there
are some uncommon situations where the trick might not work.
This is particularly likely if dealing with distributed filesystems like
NFS or AFS, or if the path you are checking is in some kind of
"union" filesystem. The trick might even work in those situations,
but I can also imagine that it might not.

--
Garance Alistair Drosehn = drosihn@gmail.com
Senior Systems Programmer
Rensselaer Polytechnic Institute; Troy, NY; USA

Paul Lutus

9/3/2006 2:04:00 AM

Garance A Drosehn wrote:

/ ...

> I expect your trick would work in very many situations, but there
> are some uncommon situations where the trick might not work.
> This is particularly likely if dealing with distributed filesystems like
> NFS or AFS, or if the path you are checking is in some kind of
> "union" filesystem. The trick might even work in those situations,
> but I can also imagine that it might not.

Yes, I agree. I thought I would add something I remember from NFS (or
perhaps its predecessor filesystem FAT32) -- it registers file times with a
granularity of 2 seconds, not 1 as you might expect. This made me
absolutely crazy when I tried to synchronize a directory on a Windows
machine from a Linux one -- the synchronization kept repeating itself
because the times refused to match up. I finally realized Windows wasn't
playing with a full deck.

--
Paul Lutus
http://www.ara...

Rick DeNatale

9/3/2006 6:46:00 PM

On 9/2/06, Paul Lutus <nospam@nosite.zzz> wrote:
> Garance A Drosehn wrote:
>
> / ...
>
> > I expect your trick would work in very many situations, but there
> > are some uncommon situations where the trick might not work.
> > This is particularly likely if dealing with distributed filesystems like
> > NFS or AFS, or if the path you are checking is in some kind of
> > "union" filesystem. The trick might even work in those situations,
> > but I can also imagine that it might not.
>
> Yes, I agree. I thought I would add something I remember from NFS (or
> perhaps its predecessor filesystem FAT32) -- it registers file times with a
> granularity of 2 seconds, not 1 as you might expect. This made me
> absolutely crazy when I tried to synchronize a directory on a Windows
> machine from a Linux one -- the synchronization kept repeating itself
> because the times refused to match up. I finally realized Windows wasn't
> playing with a full deck.

And note that you can mount various types of windows file systems in
Linux either directly or via samba.

Some of those actually let you do useful things with them. <G>

--
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denh...

Hassan Schroeder

9/4/2006 3:21:00 AM

On 9/2/06, Paul Lutus <nospam@nosite.zzz> wrote:

> Yes, I agree. I thought I would add something I remember from NFS (or
> perhaps its predecessor filesystem FAT32) --

I'd bet the engineers at Sun who originally developed the Network
File System -- NFS -- would take issue with describing FAT32 as its
"predecessor" :-)

--
Hassan Schroeder ------------------------ hassan.schroeder@gmail.com

Ara.T.Howard

9/5/2006 5:58:00 PM

comp.lang.ruby

File.ctime for detecting directory modifications?

e

Paul Lutus

e

Paul Lutus

Rick DeNatale

Paul Lutus

Garance A Drosehn

Paul Lutus

Rick DeNatale

Hassan Schroeder

Ara.T.Howard

x Login to ForumsZone