> On Tue, Feb 21, 2012 at 10:04:55PM +0000, Al Viro wrote: >> What we need to do is either >> * silently return 0 on thislen > QNX6_LONG_NAME_MAX, or >> * return 0 and yell about corrupt /longfiles, or >> * have qnx6_lookup() check that len <= QNX6_LONG_NAME_MAX and >> return ERR_PTR(-ENAMETOOLONG) if it isn't. And lose the thislen check >> completely. >> >> I'd probably go for the last variant; it's consistent with what other >> filesystems are doing and it would avoid mess if we ever try to do >> r/w variant. > > Oh, wait - you already are doing that in ->lookup()? Then it's definitely > "let's lose thislen checks in qnx6_long_match() and qnx6_match()". Dead > code is dead code... > Correct - dead code. Removed in the patch... (same location as before) A r/o driver to me always looks like "giving up half the way". (ok, maybe just one third the way) Well, I'm sure I've collected enough fs information for impelemting r/w. However, doing that still means a whole bunch of work. Already started with some parts, but that was still completely based on buffer_head stuff. My suggestion would be to do it in smaller incremental steps. (e.g. start with Bitmap handling stuff and then move on) At least I spent a lot of time on analyzing and understanding how that bitmap system area is used any calculated. I'd prefer to dump it soon out of my brain to get freed up some space ;) It would be very helpful to get some ideas on how to implement that failsafe stuff properly. (QNX calls it CoW - Copy on Write) I've described it's basic mechanics in qnx6.txt. I'm just - let's carefully say - clueless on how to approach that beast properly. Maybe first just implement simple write support (just on the active superblock) and then later - if still not tired - extend the failsafe support. Kai -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
