In <[EMAIL PROTECTED]>, on 03/20/03 at 06:28 PM, "Mitch \(WebCob\)" <[EMAIL PROTECTED]> said:
>Sam wrote: >>> What is the reason to use soft links in the shared folders? >>> >>> I would think that hardlinks (with an independance of file >>> permissions on >>> the original file) would provide advantages from a group >>> membership and maintenance point of view... >> >>The sharable mailbox may be on a different filesystem. >I was 99% certain you were goign to say that... and a valid consideration >- >so to avoid breaking things we'd probably have to allow the possibiliy of >both unless people were sure they didn't need the softlink option >(./configure option?) >>> COULD the shared folder softlink be changed to hardlinks? Would >>> it be a BIG change? >> >>First of all, there needs to be a good reason for a change. >>"Just for the heck of it" isn't going to cut the mustard. >Of course. Should go without saying but often needs to be said anyways >;-) Seriously though I think there are reasons to consider the change - >it's a matter of whether or not the impact is worth it. >1) copied messages could be handled with hardlinks instead of copies, >resulting in less data transfer and less data storage >2) shared folders could be accessed without reliance on common group >membership (which admittedly could be more than a "simple" softlink -> >hardlink change). Shared folders by hardlink would be faster (by how >much?) without having to resolve the soft link, but the permissions issue >was more of a problem for me before and I see it as a happy coincidense >of changing to a hardlink based system. >On FreeBSD 4.x (maybe this is different elsewhere, so I note it here for >later arguments ;-) one can maintain hardlinks to a single file with >completely different ownership information. >i.e. >touch stuff1 >chown user1:user2 stuff1 >chmod 700 stuff1 >ln stuff1 stuff2 >chown user1:user1 stuff2 >chmod 700 stuff2 >two names, one file, completely different and independant owners / >groups, ONE data file. >On BSD there are limits to the number of groups a user can belong to, >which can be increased by rebuilding a custom kernel (16 is the limit I >think) which unfortunately limits the complexity of managing shared >mailing lists... you can't have each list be a group, or people run out >of group membership options. Changing the limit is cautioned against >without a makeworld and also the warning that some applications MAY have >been hardcoded to the original value. >of course with alternative authentication systems (mysql) this can >probably be bypassed, but I was never confident that one wouldn't end up >bumping into the OS limit at some point as the daemon tried to access >files it would rely on the OS environment of permissions one it sets that >user id... >With hardlinks, a user can own their own copy of their messages which >just HAPPEN to be linked to the shared copy. >am I making sense? what do you think? >m/ Butting in here, but adding & supporting that extra sort of 'option' complexity w/r file storage doesn't seem to me to be an 'improvement' to courier-mta. Instead, what you want seems better suited to a DB-driven approach. There can be overhead in that - LOTS of it, but not always as bad as it might seem... If the DB stores just the path to the file containing the message, *and* to whom it may be released, then it is up to the implementor where the files are stored and how, and what tradeoffs are tolerable w/r speed, security, portability, redundancy, etc. I have been looking at ways to do something similar with integrating postgresql with courier-mta. have a look at what powerdns.com are doing with their PowerMail product, which I regard as more concept-inspirational than ready-for-production for what I need. Regards, Bill Hacker -- ------------------------------------------------------- This SF.net email is sponsored by: Tablet PC. Does your code think in ink? You could win a Tablet PC. Get a free Tablet PC hat just for playing. What are you waiting for? http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en _______________________________________________ courier-users mailing list [EMAIL PROTECTED] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
