10/09/03 chris : >If you can reconstruct the original directory structure from when the >emails were downloaded, Emailer *might* relink the attachments.
Based on my experience it *will* work. Yet Emailer won't relink the attachments globally. What it will do is that each time you'll try to access one it will "find" its copy based on its path. Afterwise it will point THAT copy, meaning you will again be able to move or rename it, but NOT every other attachment that weren't accessed. I hope this doesn't sound too confusing. The point is attachments aren't "in the attachments folder", they are alias of individual files that can be anywhere, the attachments folder being only a default download location. The consequence is that if you reproduce the paths to the attachments, Emailer will find them, and every attachment you access from Emailer will probably be linked again as an alias from then on (meaning that you could avoid keeping the old structure on the new disk only after accessing each attachment once; maybe a script could do that). As I mentioned recently, the attachments links in Emailer are really alias (or so they seem), which has some major advantages (you can't break them by moving or renaming the files), but one flaw�: it's easy to break them when you backup or move to another disk. So you CAN preserve the links if you can either�: - maintain access to the original files on the disk where they were downloaded of course, in which case the alias will work no matter if they were moved or renamed (this is the power of the alias, which relies on the file ID provided by the HFS and HFS+ filesystems, and would be considered deep magic by users of other operating systems if only they believed it) - or reproduce the path to where each attachment was last accessed from Emailer (an alias primarily relies on the file ID, but it keeps track of its path and filename each time it is accessed, in case the file ID would fail, which is inevitably the case after being copied to another disk) There's another catch though, regarding html alternatives saved as attachments (Enclosed#x.html): Emailer doesn't keep track of the last number, what happens is that each new file takes the next available number in the downloads folder. The consequence is that if you have 4 of them and you trash the 2nd attachment, the next message with html will recreate a #2, which will then appear linked from that new message, but ALSO from the older message that created the original #2. This can be confusing, that's why somebody made a script to rename html enclosures based on the date and time or the title of the message (don't ask for the script, I don't remember more). So the attachments problems in Emailer are semi-trivial: the solutions are easy, but they require either some heavy scripting or to keep the original path structure forever. I still prefer Emailer's method over mailers that either expect attachments to stay in one place relative to the database (advantage: easy backup, flaw: you can't move them), or keep them encoded within the text database like on the mail server (advantage: those can't lose track of attachments, flaw: their database grow stupidly fast and force you to decode attachments to external files to use them anyway). ---- VRic ___________________________________________________________________________ To unsubscribe send a mail message with a SUBJECT line of "unsubscribe" to <[EMAIL PROTECTED]> or <[EMAIL PROTECTED]>
