 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Mac Forum / Applications / Eudora / September 2007cannot find attachments for outgoing messages
Recently Eudora has had the following two problems 1) at Eudora start up cannot find the attachment folder; and My attachment folder is located on a disk that is connected to my computer via a LAN. The disk volume is mounted and I can navigate and set the attachment folder to the correct folder. However the next time I start Eudora it cannot find the attachment folder and displays a dialog box to that effect and gives me the choice of choosing the attachment folder again or using the default location. Eudora did not use to exhibit this behavior. Recently the disk that was connected to my computer via a LAN was replaced with a new larger disk. 2) Eudora has a broken link for attachments to outgoing messages I store my documents on the same, separate disk and in the past Eudora preserved the link to attachments on outgoing folders. Since the disk has been upgraded Eudora is no longer able to find the attachments. Any thoughts, observations that would help me begin to troubleshoot, much appreciated. > Recently Eudora has had the following two problems > [quoted text clipped - 18 lines] > > Any thoughts, observations that would help me begin to troubleshoot, Can you right-click your desktop, choose New > Shortcut, copy into the wizard the exact same (*original*) paths which Eudora won't open, then try to open your shortcuts? Potential issues could be any change from original path to new path (even a change between a drive-letter path and a UNC path), or failure to re-connect network drive (to the same letter as before), or permissions on the new disk, etc. -- Uh-oh, I did it again (thought I was reading Windows group, and wondered why my message never appeared there :) Sorry, please ignore (server ignores "cancel"). -- > Recently Eudora has had the following two problems > [quoted text clipped - 19 lines] > Any thoughts, observations that would help me begin to troubleshoot, > much appreciated. Mac OS X tracks files and folder by their inode number (sorry, Unix term) which is roughly their position in the directory. So when you move the files/folders to a new disk, they get new inode numbers. Eudora unfortunately tracks all its files and folders by their inode number, so is unlikely to get the same files after the move. That said, you can mostly get it to work properly by reselecting the attachment folder in Settings|Attachments. Cheers David > > Recently Eudora has had the following two problems > > [quoted text clipped - 26 lines] > Eudora unfortunately tracks all its files and folders by their inode number, > so is unlikely to get the same files after the move. Actually this isn't strictly a MacOS X issue and doesn't really involve inodes. HFS+ is not really an inode-based filesystem, and what MacOS X shows as an inode number is actually the closest approximation in HFS+, the "Catalog Node ID" which is an adequate substitute in most circumstances where anyone cares. It's fairly uncommon for a program of any sort to use inode numbers (or CNID's) to remember particular files, because they are not useful for accessing files through OS facilities. Eudora would never use an inode number (even for purposes where it could make sense,) because it is not coded to the classical Unix API's where the inode originates or even to the NeXT-derived Cocoa API's, but to Carbon, which is essentially a port of the classic MacOS API's to MacOS X. Carbon offers native HFS structures to applications, and they are quite suited to the sort of incident where a re-writing of a directory tree causes an app to 'lose' a file that it seems to know the name of. The way I've seen that happen is by stashing a file location only as the contents of a 'FSSpec' structure: a filename, directory ID, and volume reference number. This approach was common in ancient MacOS history, because an FSSpec is what applications actually use for classical (i.e. Carbon) MacOS file access, and they have some resilience to name changes and movements above the parent directory. Eudora is of an original vintage that makes it likely that it used that approach. The tradeoff between a saved FSSpec and a saved pathname on traditional MacOS was usually won by the FSSpec approach because it allows users to rename or move the parent directories of a file without breaking, where pathname tracking was readily broken by that. Apple uses a complex heuristic approach that has never been really documented for its "alias" structures that are more robust than either pathnames or FSSpec's, but they are also subject to being broken by major events like a disk restore onto fresh hardware. > That said, you can mostly get it to work properly by reselecting the > attachment folder in Settings|Attachments. Indeed. If that does not work, it would be a sign of serious harm to something (like the Settings file.)  SignatureNow where did I hide that website... > Actually this isn't strictly a MacOS X issue and doesn't really involve > inodes. HFS+ is not really an inode-based filesystem, and what MacOS X > shows as an inode number is actually the closest approximation in HFS+, > the "Catalog Node ID" which is an adequate substitute in most > circumstances where anyone cares. Thanks Bill. I knew HFS used something like an inode, but I never knew its name. Amend my comments to refer to the "Catalog node ID". Cheers David > > Actually this isn't strictly a MacOS X issue and doesn't really involve > > inodes. HFS+ is not really an inode-based filesystem, and what MacOS X [quoted text clipped - 4 lines] > Thanks Bill. I knew HFS used something like an inode, but I never knew its > name. Amend my comments to refer to the "Catalog node ID". Okay, clearly I was too geeky and arcane in the last post... Essentially nothing uses an inode number or HFS's similar catalog node ID as a way to remember what files or directories to access, because those numbers are not useful in retrieving files from any filesystem. The inode and CNID only exist to be absolutely unique identifiers for filesystem objects, and the way they get assigned makes them both not so useful in finding files. Instead, the problem Eudora has with losing configurable file locations when a disk is replaced (i.e. when files don't move from the view of the user, but have fresh filesystem internal details) seems to be rooted in a mechanism that dates back to the 80's for MacOS, and remembers the volume reference number, parent directory ID, and filename: a "FSSpec" structure. That data structure is precisely what one needs to access a file in a classic MacOS/Carbon environment, so a lot of older Mac programs like Eudora use it to this day and have never moved on to the somewhat more robust Alias Manager tools or to the brittle Unix tradition of fixed pathnames. Eudora COULD be smarter about this by remembering both a FSSpec or alias structure and the full pathname, and falling back to the pathname when the FSSpec or alias proves invalid. It doesn't do that and it never will, given its development status. <geeky tangential rant follows> The use of FSSpec's and MacOS aliases means that the user can do some weird things with moving and renaming folders on a Mac without Mac programs losing them. Along with multi-fork files, distinct type/creator metadata, and a handful of other cool technical details, this internal detail helped give MacOS its user-tangible edge 20 years ago and hold it. Apple has been giving up on some of those technologies because they interfere with interop, and that's a very sad thing. SignatureNow where did I hide that website... |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.