AnyEvent-Filesys-Watcher

 view release on metacpan or  search on metacpan

lib/AnyEvent/Filesys/Watcher/FSEvents.pm  view on Meta::CPAN

use constant MODIFIED => 2;
use constant DELETED => 3;
use constant RENAMED => 4;
use constant RESCAN => 5;

my %flag_type = (
	# Cannot happen.
	kFSEventStreamEventFlagNone => IGNORE,

	# Something went wrong.  We use the fallback method and re-scan the file
	# system for changes.
	kFSEventStreamEventFlagMustScanSubDirs => RESCAN,

	# Errors.  A re-scan should recover from them.  They are issued together
	# with kFSEventStreamEventFlagMustScanSubDirs.
	kFSEventStreamEventFlagUserDropped => RESCAN,
	kFSEventStreamEventFlagKernelDropped => RESCAN,

	# Self-explanatory.
	kFSEventStreamEventFlagItemCreated => CREATED,

	# Issued, when the id counter has overflown the 64 bit limit.  We ignore
	# the ids anyhow.
	kFSEventStreamEventFlagEventIdsWrapped => IGNORE,

	# Sentinel event only issued with 'since'.  It marks the end of historical
	# events.  Subsequent events are new.
	kFSEventStreamEventFlagHistoryDone => IGNORE,

	# One of the parent directories of a directory being watched has changed.
	# It could mean that the directory has vanished. Re-scan?
	kFSEventStreamEventFlagRootChanged => RESCAN,

	# Mount/unmount.  FIXME! Is this really necessary? Or does the kernel also
	# send events for all files that vanish/appear because of the mount resp.
	# unmount?
	kFSEventStreamEventFlagMount => RESCAN,
	kFSEventStreamEventFlagUnmount => RESCAN,

	# Self-explanatory.
	kFSEventStreamEventFlagItemCreated => CREATED,
	kFSEventStreamEventFlagItemRemoved => DELETED,

	# Inode meta data has changed.
	FSEventStreamEventFlagItemInodeMetaMod => MODIFIED,

	# Rename events are a pain in the neck because they are issued for the
	# source and the destination file.  We simply check the filesystem in that
	# case and create a 'deleted' or 'created/modified' event.
	kFSEventStreamEventFlagItemRenamed => RENAMED,

	# The regular modification case.
	kFSEventStreamEventFlagItemModified => MODIFIED,

	# The Finder meta data has changed.
	kFSEventStreamEventFlagItemFinderInfoMod => MODIFIED,

	# chown().
	kFSEventStreamEventFlagItemChangeOwner => MODIFIED,

	# chmod().
	kFSEventStreamEventFlagItemXattrMod => MODIFIED,

	# These should be clear.  They are, of course, not ignored, but they don't
	# modify the event type.
	kFSEventStreamEventFlagItemIsFile => IGNORE,
	FSEventStreamEventFlagItemIsDir => IGNORE,
	kFSEventStreamEventFlagItemIsSymlink => IGNORE,

	# You can actually pass a 'MarkSelf' flag to the constructor (currently
	# not supported by Mac::FSEvents).  In that case, this flag will be set,
	# whenever the event was triggered by the own process.
	kFSEventStreamEventFlagOwnEvent => IGNORE,

	# Self-explanatory.
	kFSEventStreamEventFlagItemIsHardlink => IGNORE,

	# When the link count of an inode goes to 0, the inode is removed.  If
	# the directory entry referring to it had been a hard link or was hard
	# linked, then this event is also triggered.
	kFSEventStreamEventFlagItemIsLastHardlink => IGNORE,

	# A clone is a copy on write copy of a file, see clonefile(2).  You can
	# reproduce that by right-clicking on a file in Finder and then create
	# a duplicate of that file.  Since this only accompanies a
	# kFSEventStreamEventFlagItemCreated, we can safely ignore it.
	kFSEventStreamEventFlagItemCloned => IGNORE,
);

sub new {
	my ($class, %args) = @_;

	$args{interval} = 0.1 if !exists $args{interval};

	my $self = $class->SUPER::_new(%args);

	delete $args{directories};
	delete $args{callback};
	delete $args{filter};
	my $fs_monitor = Mac::FSEvents->new({
		path => $self->directories,
		latency => $args{interval},
		file_events => $has_file_events,
		%args,
	});

	# Create an AnyEvent->io watcher for each fs_monitor
	my $alter_ego = $self;
	$self->{__mac_fh} = $fs_monitor->watch;

	my $watcher = AE::io $self->{__mac_fh}, 0, sub {
		if (my @raw_events = $fs_monitor->read_events) {
			$alter_ego->_processEvents(@raw_events);
		}
	};
	weaken $alter_ego;

	$self->_watcher($watcher);

	return $self;
}



( run in 2.965 seconds using v1.01-cache-2.11-cpan-39bf76dae61 )