From: Steve French <smfltc@us.ibm.com>
To: linux-kernel@vger.kernel.org
Cc: rml@novell.com
Subject: Re: supporting functions missing from inotify patch
Date: 13 Jul 2005 16:51:45 -0500 [thread overview]
Message-ID: <1121291505.5555.92.camel@stevef95.austin.ibm.com> (raw)
In-Reply-To: <1121286081.5555.73.camel@stevef95.austin.ibm.com>
> Is dir_notify suitable for inotify and your uses?
The six dir_notify flags obviously map better to the network protocol
which cifs can request (and which Samba server needs to respond to
various network filesystem clients) but the 11 IN_ flags do not seem
that different.
>The problem with dir_notify is that the args parameter is
> dnotify flags. Those don't map directly to inotify flags.
They almost map (11 down to 6) - Not sure how
IN_MOVE_FROM and IN_MOVE_TO
map to DN_RENAME or what DNOTIFY event delete self triggerred (inotify
splits IN_DELETE_SELF out).
The mapping of the local calls to the network filesystem wire protocol
also will be interesting.
The corresponding network filesystem protocol defines a few events that
don't make sense to Linux (changing dos attributes for a file e.g.) but
I don't think that that matters much. More important is whether it can
handle the IN_ events
[from fs/cifs/cifspdu.h]
/* Completion Filter flags for Notify */
#define FILE_NOTIFY_CHANGE_FILE_NAME 0x00000001
#define FILE_NOTIFY_CHANGE_DIR_NAME 0x00000002
#define FILE_NOTIFY_CHANGE_NAME 0x00000003
#define FILE_NOTIFY_CHANGE_ATTRIBUTES 0x00000004
#define FILE_NOTIFY_CHANGE_SIZE 0x00000008
#define FILE_NOTIFY_CHANGE_LAST_WRITE 0x00000010
#define FILE_NOTIFY_CHANGE_LAST_ACCESS 0x00000020
#define FILE_NOTIFY_CHANGE_CREATION 0x00000040
#define FILE_NOTIFY_CHANGE_EA 0x00000080
#define FILE_NOTIFY_CHANGE_SECURITY 0x00000100
#define FILE_NOTIFY_CHANGE_STREAM_NAME 0x00000200
#define FILE_NOTIFY_CHANGE_STREAM_SIZE 0x00000400
#define FILE_NOTIFY_CHANGE_STREAM_WRITE 0x00000800
Which can cause the server to report back "actions" in the notification
events sent to the client:
#define FILE_ACTION_ADDED 0x00000001
#define FILE_ACTION_REMOVED 0x00000002
#define FILE_ACTION_MODIFIED 0x00000003
#define FILE_ACTION_RENAMED_OLD_NAME 0x00000004
#define FILE_ACTION_RENAMED_NEW_NAME 0x00000005
#define FILE_ACTION_ADDED_STREAM 0x00000006
#define FILE_ACTION_REMOVED_STREAM 0x00000007
#define FILE_ACTION_MODIFIED_STREAM 0x00000008
I don't see a way to do mapping of IN_OPEN, IN_CLOSE_WRITE and IN_CLOSE_NOWRITE
to anything that makes sense to the server but the rest may be doable.
next prev parent reply other threads:[~2005-07-13 21:58 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-07-13 20:21 Steve French
2005-07-13 20:39 ` Robert Love
2005-07-13 21:51 ` Steve French [this message]
-- strict thread matches above, loose matches on Subject: below --
2005-07-13 18:43 Steve French
2005-07-13 19:12 ` Robert Love
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1121291505.5555.92.camel@stevef95.austin.ibm.com \
--to=smfltc@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rml@novell.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®