Subversion Repositories QNX 8.QNX8 LLVM/Clang compiler suite

//===- DirectoryWatcher.h - Listens for directory file changes --*- C++ -*-===//

//

// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.

// See https://llvm.org/LICENSE.txt for license information.

// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception

//

//===----------------------------------------------------------------------===//

#ifndef LLVM_CLANG_DIRECTORYWATCHER_DIRECTORYWATCHER_H

#define LLVM_CLANG_DIRECTORYWATCHER_DIRECTORYWATCHER_H

#include "llvm/ADT/ArrayRef.h"

#include "llvm/ADT/StringRef.h"

#include "llvm/Support/Error.h"

#include <functional>

#include <memory>

#include <string>

namespace clang {

/// Provides notifications for file changes in a directory.

///

/// Invokes client-provided function on every filesystem event in the watched

/// directory. Initially the watched directory is scanned and for every file

/// found, an event is synthesized as if the file was added.

///

/// This is not a general purpose directory monitoring tool - list of

/// limitations follows.

///

/// Only flat directories with no subdirectories are supported. In case

/// subdirectories are present the behavior is unspecified - events *might* be

/// passed to Receiver on macOS (due to FSEvents being used) while they

/// *probably* won't be passed on Linux (due to inotify being used).

///

/// Known potential inconsistencies

/// - For files that are deleted befor the initial scan processed them, clients

/// might receive Removed notification without any prior Added notification.

/// - Multiple notifications might be produced when a file is added to the

/// watched directory during the initial scan. We are choosing the lesser evil

/// here as the only known alternative strategy would be to invalidate the

/// watcher instance and force user to create a new one whenever filesystem

/// event occurs during the initial scan but that would introduce continuous

/// restarting failure mode (watched directory is not always "owned" by the same

/// process that is consuming it). Since existing clients can handle duplicate

/// events well, we decided for simplicity.

///

/// Notifications are provided only for changes done through local user-space

/// filesystem interface. Specifically, it's unspecified if notification would

/// be provided in case of a:

/// - a file mmap-ed and changed

/// - a file changed via remote (NFS) or virtual (/proc) FS access to monitored

/// directory

/// - another filesystem mounted to the watched directory

///

/// No support for LLVM VFS.

///

/// It is unspecified whether notifications for files being deleted are sent in

/// case the whole watched directory is sent.

///

/// Directories containing "too many" files and/or receiving events "too

/// frequently" are not supported - if the initial scan can't be finished before

/// the watcher instance gets invalidated (see WatcherGotInvalidated) there's no

/// good error handling strategy - the only option for client is to destroy the

/// watcher, restart watching with new instance and hope it won't repeat.

class DirectoryWatcher {

public:

  struct Event {

    enum class EventKind {

      Removed,

      /// Content of a file was modified.

      Modified,

      /// The watched directory got deleted.

      WatchedDirRemoved,

      /// The DirectoryWatcher that originated this event is no longer valid and

      /// its behavior is unspecified.

      ///

      /// The prime case is kernel signalling to OS-specific implementation of

      /// DirectoryWatcher some resource limit being hit.

      /// *Usually* kernel starts dropping or squashing events together after

      /// that and so would DirectoryWatcher. This means that *some* events

      /// might still be passed to Receiver but this behavior is unspecified.

      ///

      /// Another case is after the watched directory itself is deleted.

      /// WatcherGotInvalidated will be received at least once during

      /// DirectoryWatcher instance lifetime - when handling errors this is done

      /// on best effort basis, when an instance is being destroyed then this is

      /// guaranteed.

      ///

      /// The only proper response to this kind of event is to destruct the

      /// originating DirectoryWatcher instance and create a new one.

      WatcherGotInvalidated

    };

    EventKind Kind;

    /// Filename that this event is related to or an empty string in

    /// case this event is related to the watched directory itself.

    std::string Filename;

    Event(EventKind Kind, llvm::StringRef Filename)

        : Kind(Kind), Filename(Filename) {}

  };

  /// llvm fatal_error if \param Path doesn't exist or isn't a directory.

  /// Returns llvm::Expected Error if OS kernel API told us we can't start

  /// watching. In such case it's unclear whether just retrying has any chance

  /// to succeed.

  static llvm::Expected<std::unique_ptr<DirectoryWatcher>>

  create(llvm::StringRef Path,

         std::function<void(llvm::ArrayRef<DirectoryWatcher::Event> Events,

                            bool IsInitial)>

             Receiver,

         bool WaitForInitialSync);

  virtual ~DirectoryWatcher() = default;

  DirectoryWatcher(const DirectoryWatcher &) = delete;

  DirectoryWatcher &operator=(const DirectoryWatcher &) = delete;

  DirectoryWatcher(DirectoryWatcher &&) = default;

protected:

  DirectoryWatcher() = default;

};

} // namespace clang

#endif // LLVM_CLANG_DIRECTORYWATCHER_DIRECTORYWATCHER_H