Você não pode ter o kernel apenas informando sobre uma alteração em um determinado caminho. Os motivos são um pouco sutis:
No Linux, um objeto de arquivo existe independentemente de qualquer nome (s) que possa ter. Os nomes dos arquivos são, na verdade, atributos do diretório que os contém, e um único arquivo pode ser chamado por vários nomes (consulte, links diretos).
O kernel precisa ter algo para anexar inotificar objetos; ele não pode anexar um objeto a um nome de caminho, pois um nome de caminho não é um objeto real do sistema de arquivos; você precisa anexar ao diretório pai ou ao arquivo que o caminho descreve. Mas você não pode anexar ao arquivo, porque está assistindo para ver se um arquivo com um determinado nome é criado, não muda para um determinado arquivo.
Teoricamente, o kernel pode implementar uma API que permite selecionar eventos para um determinado nome de caminho ao adicionar um monitor a um diretório, da mesma maneira que permite selecionar tipos de eventos. Isso iria inchar a API e, no final, o kernel processaria os mesmos dados e faria a mesma comparação de strings que você faria no espaço do usuário.
Existe um desempenho perceptível ao colocar um relógio em um diretório muito ativo? Não tenho certeza de quão ativo você está falando; dezenas de arquivos por segundo, centenas, milhões?
De qualquer forma, eu evitaria access
: sempre será uma corrida. Um arquivo pode ser criado e removido entre as chamadas para access
, e a chamada access
em um loop muito apertado será lenta e é o tipo de problema que inotify
foi projetado para resolver.
access
comF_OK
para ver se ele já existe.