At 7:41 PM -0600 3/26/07, [EMAIL PROTECTED] wrote: >On Mar 27, 2007, at 00:22 UTC, Steve Upton wrote: > >> >Well, you can give it exactly the final folderitem you want it to be >> >(make destFile the actual file rather than a directory). >> >> yeah, thought about this one, but actually want it to work with the >> original file name... > >You can have it do so, just by constructing the destination filename >using the original filename and the destination directory. But that >gets us right back to your other issue.
right... > >> Here's the actual path information: >> >> Original filename: CX default cal 9_16_05-4270D40.icc Filename in RB >> : CX default cal 9_16_0#7B558.icc > >As viewed with what? .Name? .DisplayName? .AbsolutePath? Something >else? .name - and looking in the debugger, basically any other path property all have the truncated file name. > >> It copies over just fine but, as you can see, I don't have access to >> the correct file name, so I can't directly access the file. I can >> hunt through the folder using .item, etc but I want something that's >> going to work in general use. > >dir.TrueChild(f.Name) should work just fine; it always has for me (and >yes, I've tested it on long filenames). Is this some unusual file >system? Not HFS+? A network drive? Normal HFS+ on a G4 Powerbook, nothing weird here. I don't know if I have an answer but I do have more information: - This is all occurring in the /Library/ColorSync/Profiles/Display folder. This folder and its contents are created by ColorSync and the profiles are moved/copied (not sure which) over to the folder when selected by the user in the Displays panel. I don't know if this is a good hint but I have heard that things in this folder behave strangely - but details of what I heard is not available to my memory at this time :-/ - As a work-around, and due to the special case where I was creating a new folder in the temporary file location and my file would be guaranteed to be the only file in the folder, I decided to use folderitem.item(1) to grab the folderitem for my newly copied file. It turns out that once I copy the file to the new location and grab the folderitem in this manner it has the correct, non-truncated file name available to me and behaves just as it should. So, I guess what I am observing is some rather odd behavior for a certain folder on the OS. I'd surely like to know the reason behind this oddity but I now have a workaround and can go back to work.... Anyone else heard strange things about this ColorSync Profiles folder? Regards, Steve -- _______________________________________________ Unsubscribe or switch delivery mode: <http://www.realsoftware.com/support/listmanager/> Search the archives: <http://support.realsoftware.com/listarchives/lists.html>
