From nobody Sat Aug 13 15:35:21 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4M4l4B2PNkz4Z5sd for ; Sat, 13 Aug 2022 15:35:38 +0000 (UTC) (envelope-from 6yearold@gmail.com) Received: from mail-vs1-f46.google.com (mail-vs1-f46.google.com [209.85.217.46]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4M4l4927wkz49Tk for ; Sat, 13 Aug 2022 15:35:37 +0000 (UTC) (envelope-from 6yearold@gmail.com) Received: by mail-vs1-f46.google.com with SMTP id q15so3500105vsr.0 for ; Sat, 13 Aug 2022 08:35:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=n/AFrS3LUJpQ+sgjMlZiaebJPGAKEEfLIUaHZm0svIs=; b=nfbQQz+P/JGmh+d5eNB/vG1vyJkksSfPjUbv3/Expvv2NkJjo1GMQ983zG0sXZUDBO msnf96WHkv4r7f606uC42S3aYwJ+CtJzAei7VPwGaZ00DckcupZ95c3/EvjffOd+13s6 gC+DyXh4FQOVTujvgDMwDWJSyfmkTMc4I1VE3eHJuG2HqXLp29qXGuxgW3we5iD+yJTx 1uccEHLNDoHIdcDlIfLhn8vXnLn70x61W7otfbAsV6iBLru4rOk1q4BtwXUwGIrFVtRc gOD3D9j3ZLc1tQ4ksNC3Yv35dRLUZ72TGdQ8rpcigVn/QRdGxZdnHeYllNMfzlFnwJxY peBQ== X-Gm-Message-State: ACgBeo19qtdlYQ8ybZPSWislhnmFzOHpvOdDiv1Dn8VfhiX9TzLvxBCP JJ7jhsCLd/MtSG6u0vQPlTv2mkBSt/OEvQ== X-Google-Smtp-Source: AA6agR4nNWDBGAYb0YkFoCKfR03VoS+z7mu3fcO+4vtgGWdEIzvzJc6JkLfudpZBLpkdIXHKJlAuvw== X-Received: by 2002:a05:6102:5e6:b0:385:361:5892 with SMTP id w6-20020a05610205e600b0038503615892mr3648077vsf.7.1660404936025; Sat, 13 Aug 2022 08:35:36 -0700 (PDT) Received: from mail-vk1-f176.google.com (mail-vk1-f176.google.com. [209.85.221.176]) by smtp.gmail.com with ESMTPSA id y12-20020ab05b8c000000b003844b2e1462sm2124133uae.13.2022.08.13.08.35.35 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 13 Aug 2022 08:35:35 -0700 (PDT) Received: by mail-vk1-f176.google.com with SMTP id bi51so1826209vkb.5 for ; Sat, 13 Aug 2022 08:35:35 -0700 (PDT) X-Received: by 2002:ac5:cb6e:0:b0:37d:2a0b:af66 with SMTP id l14-20020ac5cb6e000000b0037d2a0baf66mr3836740vkn.30.1660404935319; Sat, 13 Aug 2022 08:35:35 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <652f3c12-388c-04d0-ebeb-753b76b2b742@gmail.com> In-Reply-To: <652f3c12-388c-04d0-ebeb-753b76b2b742@gmail.com> From: Gleb Popov Date: Sat, 13 Aug 2022 18:35:21 +0300 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: How to monitor a directory in FreeBSD? To: meator Cc: freebsd-hackers Content-Type: multipart/alternative; boundary="0000000000005a65d605e6212676" X-Rspamd-Queue-Id: 4M4l4927wkz49Tk X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of 6yearold@gmail.com designates 209.85.217.46 as permitted sender) smtp.mailfrom=6yearold@gmail.com X-Spamd-Result: default: False [-1.36 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; NEURAL_HAM_LONG(-0.36)[-0.356]; FORGED_SENDER(0.30)[arrowd@freebsd.org,6yearold@gmail.com]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TAGGED_RCPT(0.00)[]; DMARC_NA(0.00)[freebsd.org]; RCVD_TLS_LAST(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCVD_IN_DNSWL_NONE(0.00)[209.85.217.46:from,209.85.221.176:received]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_TWO(0.00)[2]; TO_DN_ALL(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; ARC_NA(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; FREEMAIL_ENVFROM(0.00)[gmail.com]; R_DKIM_NA(0.00)[]; FROM_NEQ_ENVFROM(0.00)[arrowd@freebsd.org,6yearold@gmail.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.217.46:from] X-ThisMailContainsUnwantedMimeParts: N --0000000000005a65d605e6212676 Content-Type: text/plain; charset="UTF-8" On Sat, Aug 13, 2022, 15:16 meator wrote: > Hello. I'm working on a C program that needs to know whether files and > directories in a specific directory were added, modified or deleted. (It > should also be done recursively for all subdirectories, but to keep it > simple I don't take recursion into account. It shouldn't be that hard to > implement it after I will be able to monitor a directory nonrecursively.) > > I don't have much experience with BSD programming but I know POSIX. I > have used inotify before for this purpose, but BSD doesn't have it so I > started looking for BSD alternatives. The internet lead me to kqueue. I > saw some criticism of it, but I don't need to monitor several thousands > of files, so I hope it will be usable for my use case. > > The EVFILT_VNODE filter documentation in kqueue(2) doesn't really talk > about files and directories, it talks about file descriptors. Inotify on > the other hand is very explicit about handling files in the monitored > directory. Kqueue can still detect creation and deletion of files inside > the monitored directory with NOTE_WRITE for files and NOTE_LINK for > directories (at least I think, I made a little test program to test this). > > This is useful, but I don't see any obvious way to identify a newly > created file inside the monitored directory. File creation would result > in NOTE_WRITE, but struct kevent doesn't have any "name" field (unlike > inotify) that would show which file was created. I would have to make a > list of directories and compare the old state with the current state to > see the file which was added. > > Kqueue also doesn't seem to detect modification of files inside the > monitored directory. Does this mean that I would have to monitor every > single file in the directory to make this work? > > I think this shows that kqueue isn't really meant to be used for > monitoring directory members. Is this true? Have I misunderstood something? > Yes, there is no native API to monitor directories. You can use libinotify from ports, which replicates Linux inotify API and it does have ability to monitor directories. > --0000000000005a65d605e6212676 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sat, Aug 13, 2022, 15:16 meator <meator.dev@gmail.com> wrote:
Hello. I'm working on a C program that needs = to know whether files and
directories in a specific directory were added, modified or deleted. (It should also be done recursively for all subdirectories, but to keep it
simple I don't take recursion into account. It shouldn't be that ha= rd to
implement it after I will be able to monitor a directory nonrecursively.)
I don't have much experience with BSD programming but I know POSIX. I <= br> have used inotify before for this purpose, but BSD doesn't have it so I=
started looking for BSD alternatives. The internet lead me to kqueue. I saw some criticism of it, but I don't need to monitor several thousands=
of files, so I hope it will be usable for my use case.

The EVFILT_VNODE filter documentation in kqueue(2) doesn't really talk =
about files and directories, it talks about file descriptors. Inotify on the other hand is very explicit about handling files in the monitored
directory. Kqueue can still detect creation and deletion of files inside the monitored directory with NOTE_WRITE for files and NOTE_LINK for
directories (at least I think, I made a little test program to test this).<= br>
This is useful, but I don't see any obvious way to identify a newly created file inside the monitored directory. File creation would result in NOTE_WRITE, but struct kevent doesn't have any "name" fiel= d (unlike
inotify) that would show which file was created. I would have to make a list of directories and compare the old state with the current state to see the file which was added.

Kqueue also doesn't seem to detect modification of files inside the monitored directory. Does this mean that I would have to monitor every
single file in the directory to make this work?

I think this shows that kqueue isn't really meant to be used for
monitoring directory members. Is this true? Have I misunderstood something?=

= Yes, there is no native API to monitor directories. You can use libinotify = from ports, which replicates Linux inotify API and it does have ability to = monitor directories.
--0000000000005a65d605e6212676--