On Wed, Jan 09, 2002 at 01:41:28PM -0500, Jeffrey Stedfast wrote:
Unfortunately, no. I made no changes whatsoever to the mailboxes. I just entered them to see if the messages showed up, they did, then I exited. Thats when I noticed the symlinks had been blown away, and the resulting "copied" mailbox was bigger in size than the original!Ah, I bet I know why... Evolution added an X-Evolution header to each message for status purposes. The X-Evolution header contains an encoded UID and message flags. That would also explain why it got bigger than the original file.
Fair enough. Pine does something similar. Can it be gauranteed that the Quoted Printable encoding hasn't been decoded then reencoded in the process?
Actually, this isn't guaranteed to work :-( rename() is unfortunately limited to renaming files on the same file system, once you add symlinks to the equation - you could be leaping across file system boundaries and there isn't a way to tell (well, ok, so you can check st.st_dev and compare the 2). The only way I can think of to get around this is to create the tmp mbox file in the same directory as the original (after being realpath()'d). This may also have problems - what if you don't have write-permission in that directory?
You solved the problem. That is the correct solution. After running realpath(), use dirname() and make the tmpfile in the same directory as the mailbox. The perception of a possible permissions problem is bogus. If you don't have permission in that directory to create the tmp mailbox, then you probably didn't have permission to blast over the original mailbox either. Suppose you successfully created the tmp file, but the rename() failed? I mean, it *could* happen. But its not likely. If such operations as creating the tmp file, or renaming it fail, that means the user has set the permissions himself, in which case he probably wanted that to happen. So don't complain, and leave the mailbox as is. Remember, "stupid" users will try to do everything from the GUI you provide. Users savvy enough to fiddle with ln, touch, chown, and chmod will get angry and exceedingly frustrated if you treat their actions the same as you treat those of your target "stupid" user.
Again, provided one uses Maildir mailboxes, things will be fine. But the thought occurs, Evolution should do its "locking" on the file returned from realpath() too.You are probably right.
I've thought about it some more, and I'm upgrading my "maybe" to a strong "this is the proper way to do it". Symlinks should not be locked. They should be followed with realpath() and the real mailbox should be locked, like other MUA's do. This will truly make it compatible and play nicely on the Unix system. Cheers! Jonathan -- I am working to subvert from within ... umm ... by writing shoddy code ... and charging too much. -- Colin, Aug 21, 2001
Attachment:
pgpGBSvBwuByA.pgp
Description: PGP signature