Hi Christopher,
Try to keep file names short when naming files in apps that seem
to change to the hex name with longer file names (now we perhaps
know which programs are still getting caught with their shorts
down huh?)
Bwhaa! (spit tea all over my screen again! Bad, BAD Finale lister!)
But good advice.
Sorry 'bout that!! :-) I'm feeling a little grumpy over needing to
buy 2008 now when I have barely even used 2007 'cause of the
instability... But, just for the record, I still love Finale
overall! (is that better?)
No, I have not seen a kernel panic yet (but the year is still
young!) I see that I may have been extraordinarily lucky so far.
That's good!
Do you think that perhaps renaming a hexed file to a shorter name
could save me, even if it has been that way for a while through
multiple saves? Or do you think that if I don't catch it at the
first save then the file is trashed? I suspect that copying the
contents to a fresh file would save me, too.
If it isn't already corrupted yes, renaming the file to something
shorter should fix the problem. I would definitely change the name
of any file that has hex in the name as soon as I saw it come up that
way.
Also, as long as you haven't copied the file to another volume or
computer while it has the hex in the file name, the file should be
alright still even if you have done several saves.
As I understand it, the inode number that is being translated to hex
when the name is too long describes exactly where the file lives in
the filesystem of a particular machine where the name conversion took
place (a unique number that applies only to that machine and its
filesystem.) So if you drag the hex named file to another volume
with a different filesystem, that number (in the form of the hex
string) no longer applies on the new machine's or volume's filesystem
and that is where the trouble begins. If you have a "good" non-hex
named file and transfer it, well, a name is a name is a name and it
can live anywhere so the new file system will know what to do. :-)
Try a Google search on "31 characters hex filename" I found this for
you when I did that search:
http://www.macworld.com/forums/ubbthreads/showflat.php?
Cat=0&Number=498611&Main=497508
This part especially (they are calling it a vnode in the link I found
for you below rather than inode):
******
A developer gives a more technical perspective: "I am positive this
is due to the developer using FSSpecs to references files instead of
the new FSRef. FSSpecs only support 31 char file names and may also
barf on UFS disks."
Another developer confirms: "This behavior is actually described by
Apple. The HFS+ file system is capable of very long file names. When
such a file name is presented to an application using the Navigation
Services interface, returning a FSSpec (File System Spec), the name
will be encoded in this fashion. The element after the # is actually
the "vnode" for the file. The encoding is designed to be two way, so
that most of the time references to the file will work properly from
Classic or Carbon applications. The new HFS+ function calls use
FSRefs to refer to files, and they can have the full size file name.
The FSRef can be used in Mac OS 8.1 or later if they are supported by
the file system."
****
(He said barf!! ha..ha..)
So it looks like perhaps Finale (and some of my other apps too so as
to not just pick on Finale!) is still using FSSpec rather than FSRefs.
Hope you had a good weekend!
:-)
-K
_______________________________________________
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale
