2012/11/30 Steve French <smfrench@xxxxxxxxx>: > On Thu, Nov 29, 2012 at 5:14 PM, Stef Bon <stefbon@xxxxxxxxx> wrote: >> 2012/11/29 Al Viro <viro@xxxxxxxxxxxxxxxxxx>: >>> On Thu, Nov 29, 2012 at 09:31:05PM +0100, Stef Bon wrote: >>>> 2012/11/29 Al Viro <viro@xxxxxxxxxxxxxxxxxx>: >>>> > On Thu, Nov 29, 2012 at 05:39:27PM +0100, Stef Bon wrote: >>>> > >> >>>> With Ubuntu people started Unity, also without a killer app, but just >>>> with an opinion, an impression, an idea. And anyone can dislike or >>>> like it, it's a succes as far as I can see. What the hell is wrong >>>> with suggesting things based upon an idea/impression? >>> >>> IOW, it was a true positive for "([Uu]ser experience)|UX" as BS predictor. >>> Nice to know... >>> >>> Look, you'd been asked to give good reasons for doing some thing; replying with >>> "it's My Opinion(tm), piss off if that's not enough reason for you" would at >>> least have been honest. References to UX, as your last reply has confirmed, >>> had been basically an obfuscated equivalent of that. >> >> No no, I do not say "piss off". If that is what my message looked >> like, I'm sorry for that. But I do not have any killer app or >> something. I cannot convince you otherwise that saying it's my >> opinion. I do not have numbers or something like that proving I have a >> point. I wish I have. But I do understand you do not agree with me, >> and see things different. >>> >>> Sorry for being harsh, but I've had it with the GNOME crowd and their ilk >>> using just such references to handwave away any questions. >>> >>> There's nothing wrong with having opinions/impressions/etc. Everyone got >>> their own, etc. But "I believe so, period" is not a sufficient answer to >>> "what makes that a good idea?" and obfuscating it up is even worse. >> >> So, no I do not say "I believe so, period" . But I cannot convince you >> ...and we have different opinions here.. I don't know any method here >> of "proving having a point". > > One question that hasn't been answered AFAIK is how well the current > Linux directory change notification API maps to the needs of its principal user > (presumably Samba, and kde/gnome file managers), and a loosely > related question of how well the change notification API maps to the > corresponding network file system protocol operations > (TRANSACT_NOTIFY_CHANGE) which is a fairly common operation > sent to Samba, and obviously for the cifs/smb2/smb3 case would limit > what types of events the client can notify the desktop/file manager about. > > In particular, the 10 or 15 filter flags, and the (at least) 8 events > (add/remove/modify/rename etc.), > available in tne network protocol AFAIK have not been matched to see if they > match closely to the existing Linux API. Hi, I start working on the seperate notifyfs servers. The whole advantage of that approach is that you can design the api from scratch. Notifyfs is not bound to the api of inotify. There remains the problem of mapping it to the fs event api on the host, which will be inotify probably on linux. At this moment the different events look like: #define NOTIFYFS_FSEVENT_META_ATTRIB_NOTSET 2 #define NOTIFYFS_FSEVENT_META_ATTRIB_MODE 4 #define NOTIFYFS_FSEVENT_META_ATTRIB_OWNER 8 #define NOTIFYFS_FSEVENT_META_ATTRIB_GROUP 16 #define NOTIFYFS_FSEVENT_META_ATTRIB 28 #define NOTIFYFS_FSEVENT_META_XATTR_NOTSET 32 #define NOTIFYFS_FSEVENT_META_XATTR_CREATE 64 #define NOTIFYFS_FSEVENT_META_XATTR_MODIFY 128 #define NOTIFYFS_FSEVENT_META_XATTR_DELETE 256 #define NOTIFYFS_FSEVENT_META_XATTR 448 #define NOTIFYFS_FSEVENT_FILE_NOTSET 512 #define NOTIFYFS_FSEVENT_FILE_MODIFIED 1024 #define NOTIFYFS_FSEVENT_FILE_SIZE 2048 #define NOTIFYFS_FSEVENT_FILE_OPEN 4096 #define NOTIFYFS_FSEVENT_FILE_READ 8192 #define NOTIFYFS_FSEVENT_FILE_CLOSE_WRITE 16384 #define NOTIFYFS_FSEVENT_FILE_CLOSE_NOWRITE 32768 #define NOTIFYFS_FSEVENT_MOVE_NOTSET 65536 #define NOTIFYFS_FSEVENT_MOVE_CREATED 131072 #define NOTIFYFS_FSEVENT_MOVE_MOVED 262144 #define NOTIFYFS_FSEVENT_MOVE_MOVED_FROM 524288 #define NOTIFYFS_FSEVENT_MOVE_MOVED_TO 1048576 #define NOTIFYFS_FSEVENT_MOVE_DELETED 2097152 #define NOTIFYFS_FSEVENT_FS_NOTSET 4194304 #define NOTIFYFS_FSEVENT_FS_MOUNT 8388608 #define NOTIFYFS_FSEVENT_FS_UNMOUNT 16777216 #define NOTIFYFS_FSEVENT_FS_NLINKS 33554432 Note that there is no such thing as watching changing xattr at this moment right now on linux. The field st_ctime is changed, nothing more. Stef -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
