Expression >
Forums Home
>
Expression Studio Forums
>
Expression Media
>
Please Fix file/folder name length issues on Mac (3+ year-old bug!)
Please Fix file/folder name length issues on Mac (3+ year-old bug!)
- xMedia on Mac does not handle file or folder names over 31 characters correctly. Sure, it LOOKS like it does, but try moving the catalog, with files referenced to a shared network volume, to another machine and watch all the files with names greater than 31, or files under any parent folders with names over 31 (even worse), become orpahned. All catalog media items have the #hash added to their names and become broken path links to the originals. All items with paths under any parent folder with 31+ characters become lost, which is even worse, since this applies to all media items regardless of file name length.
The newly unrecognized, orpaned media items cause xMedia to re-import (if you update a folder) the same files again, causing yet more problems with duplicates.
This makes xMedia on a Mac about as useful in a file server configuration as it is to run Mac OS 9 instead of OS X on a Mac these days.
Since our company has invested large quantities of coin on this product, and we love it otherwise, I have had to make extensive AppleScripts to deal with this issue. They are available here:
http://media.bhigr.com/xmedia/xMedia_FileLengthScripts.zip
(25 KB)
The archive contains 3 scripts:
Make Folders > 31 Set.scpt
Make Filename > 31 Set.scpt
These two scripts make catalog sets out of files that have issues from the current shown set of media items:
Filename Length.scpt
This script shows file lengths for selected media items, then offers to select those with 31+ characters, or just the next length that is above 31 (which is useful when batch re-naming).
There is no support for these scripts. Use at your own risk. Re-write or edit them if you like. The scripts do not change any actual file names; they just show you which ones will be a problem when referenced off of a network volume, when the catalog is shared with other users on different Macs. In other words, without fixing these problems, xMedia catalogs continually break when used with a file server and longer than 31 character file or folder names.
This is a serious bug that needs addressed, and has been around ever since OS X came out and xMedia (then, iView) became a carbon app.
Larry S- Edited byLarry_S Tuesday, April 28, 2009 11:17 PMchanged subject
Answers
- The issue was reproduced after p_horn filed his bug on the Connect site, and I replied on 9/25.
Bugs have been filed for both the CD folder name and the long file name issues... That's all I can do.
Anita- Marked As Answer byAnita OakleyMSFT, ModeratorWednesday, November 04, 2009 4:39 PM
All Replies
- Also, here's a script to help ferret-out folder name(s) that have more than 31 characters (works on a single selected item in catalog):
Foldername Length.scpt
http://media.bhigr.com/xmedia/xMedia_FolderLengthScript.zip
(11 KB)
Larry S
- Hello Larry,
Have you upgraded to SP2? We did a lot of work on folder management in SP2, though I can't guarantee that it's been fixed. I don't see a specific bug on this. But to test correctly, try it with a new catalog. I know you already have a lot of existing catalogs. This is just to see if the work has been done.
Thanks,
Anita Oakley
Microsoft Expression Media - Hi Anita,
Thanks for the reply. Yes, I am working with the latest SP2. However, I will check to make sure everyone on my network is using the latest.
Try it out for yourself. Make a catalog that references files and/or folders with 31+ characters in their name on a mounted network volume, through AFP and where the volume root is mounted, not a share point within a volume. Now, send the catalog to another Mac on the network. On the second Mac, open the catalog and choose 'Update Folder Now...' of any parent folders in the Organize Panel and Expression Media will bring in new media items for the referenced files. The previous media items for files/folders with long names no longer have their paths referenced properly and become orphaned duplicates - very bad, especially if there is catalog-only data/annotaions associated with the items.
This seems to stem from the use of an outdated file handling library that is used. Also, it sometimes occurs even with referencing on the local volume, but that may stem from the use of older catalogs. I have a specific case on my Mac, as I have a copy of our photo server running locally. When I open up the catalogs, they 'see' the local volume, but everyone else on the network sees the photos served from a different Mac when they use the uploaded catalogs (I synchronize with the server). There is no problem with this excepting the long file name issue, which still occurs in every Mac's Expression Media in the network.
BTW, it takes 4+ hours to rebuild our main catalogs (each); so, I really need to know if it is catalog-based before I go down that road.
Thanks for the help,
Larry - Ok - will test this afternoon!
Anita - Hi Larry,
I followed those instructions, except for mounting to the volume root - I don't know how to do that. When I bring up the server, it gives me options to what to mount the volume to - Applications, users, etc. The first thing in the list is selected, and you have to connect to something in the list.
I connected to one of the usernames, and placed the files on the desktop. Created a catalog on one machine. Moved to the other machine. Loaded the same catalog from thumb drive. Connected as the same user and could not reproduce the issue. So here are my questions:
1. These people are logged in as themselves, right? Not the same user from two different machines.
2. The catalog is uploaded to the server? Or is a copy kept on each user's machine?
3. Where are the media files stored, and where are the catalogs? (user folders, public folders?)
Actually, if you want to open a case so we can really talk and get the repro nailed down, please email us at xmforum at microsoft.com. We want to make sure that we have bugs documented as soon as possible. This will not cost you a support call.
Regards,
Anita Oakley - I have the same problem with files longer than 31 characters and already posted this to "Microsoft Connect" (https://connect.microsoft.com/Expression/feedback/ViewFeedback.aspx?FeedbackID=461562 ) may, the 29th, 2009. But no answer yet – no "connection" ... :-(. It's hard to find out were to post suggestions or bug reports and get an answer of Microsoft .... Now I found this forum thread.
I use the latest version of ExpressionMedia (v2.0.2 -2096- with SP2 installed) and OS X 10.5.7 (had the problem also with OS X 10.4.11) ...
I did a lot of experimentation with the problem, and perhaps this helps to show the problem (or ONE part of the problem?) ... Here is my posting to Microsoft-Connect:
------------
This is a very serious problem which prevents easy migration of the base catalog folder to another volume:
When using "Reset folder path" to change the location of an catalog folder to another location (with the same files as the original location) and then using "Update folder now" with this changed folder, ALL FILES WITH LONG FILES NAMES are added again as duplicates.
"Long file names" means more than 31 characters - the old old old old old old old old old old OS 9 limitation!!! - I can't believe that this limitation is still a problem for a modern software which I want to use in a production environment!!!
I found no workaround to prevent this except by using "Rebuild items" on all items with long file names (which is no fun with many items!!!). And I am not sure if this helps in any case, because I had a different experience with a large catalog (15000 items), but am not sure if if just forgot to use "Rebuild items" one time ... Anyway - it should not be necessary to use "rebuild items"!!!
"Find duplicates" will find these duplicates, but wants to delete the ***newer*** (just added) ones - which ends in a loop if you delete them and use "Update folder now" again. And deleting the older ones is not a good solution, because you will loose catalog sets, labels, ratings (if they are not saved as metadata inside of the files, which is not possible with every file type). And you loose the correct "archived" date!
Bye the way: It is not necessary to change the path to another volume and this bug it is 100% reproduceable for me.
Example setting:
Base_Folder_A
31_characters___12345678901.JPG
32_characters___123456789012.JPG
Base_Folder_B
31_characters___12345678901.JPG
32_characters___123456789012.JPG
Both folders can be on the same volume, even inside of one parent folder.
Step 1: new catalog, import Base_Folder_A
Step 2: Organize Panel - Catalog folders - "Reset folder path" to "Base_Folder_B"
Step 3: "Update folder now"
Result: file "32_characters___123456789012.JPG" is added as a duplicate!
I hope that this problem will be on top of the "to do" list for the next update and that there will be a next update at all. And I am wondering if Microsoft is giving up support for Expression Media, because the last update is long ago ...
Best regards,
Patrick Horn
REPRO STEPS:
See also description above.
1.) create two folders (A and B) containg (the same) 2 images (one with a short name up to 31 characters), one with a large name (32 characters or more)
2.) create a new catalog, import Folder A
3.) "Reset Folder Path" to folder B
4.) "Update Folder now" with folder B
Result: file with 32 characters will be added again as a duplicate item!- Edited byp_horn Friday, June 12, 2009 1:29 PM
- Has anybody read this posting? Perhaps anybody from Microsoft? Or any user of this forum? Would be nice to get any statement to this problem. I've already put a lot of time and work in this problem inluding analysing and two nights of "repairing" a database with many duplicates caused by this (imho) BUG!
Thanks in advance,
Patrick Horn - Patrick,
I don't know why they can not reproduce the bug (it is definitely a serious bug ). I spend inordinate amount of time and energy making sure everything is kept below 31 characters. Anita offered to work with me on resolving the issue, but I have not had time to commit. Maybe she can help you out on this.
You are correct. Your bug steps from the previous post are 100% reproducible on all my test Macs with every version of Expression Media (and iView MediaPro 3) that I have. No remote volume issue, as all fail locally. That should help solve the problem. If they can not reproduce it now then we must be living in an alternative dimension.
Unfortunately, we now have to wait for a fix, AND wait for the next release, which is way too long between production cycles these days.
Larry - Patrick,
Using your REPRO STEPS, but with 31+ character folder names, I could not reproduce the duplicate bug. So, I looks like, in the new version, they have at least fixed the issue with parent paths that exhibit 31+ characters. File names with 31+ characters still cause the duplicate bug. Appears to be an issue with the import item code that causes the long file name to be internally recorded incorrectly, leading to a duplicate on the next folder update. Really a big pain.
Larry - Hello Larry!
Nice to hear from you. Thank you ... And thank you for confirming my repro steps.
Long folder names: yes, I also have noticed that I have no problems with long folder names since some time (one of the last updates has fixed something, but not everything ...). Only thing I don't have tested yet is the command "Backup/CD-ROM" which also had a long folder name (or long file name?) problem (I used it some time ago to copy a large amount of files from a catalogue to another volume with keeping the folder structure; can be useful; long files names were cut to e.g. "xyzxyzx#5389D").
It seems that the problem is hard to locate in the source code of the software and they have to fix it on several positions ... but that's not my business, it's Microsoft's. And they should do their work ... do it better! ... PLEASE!
Now I really feel like a beta tester not getting any compensation for my work and analysis of the problem but only trouble. They could at least answer here (or at "Microsoft Connect") and say if they will fix this in the next update ... or send us a big strawberry cake or something else for compensation.. ;-)
And yes, you are right, it's a big pain in a production environment. I really cannot change all files to 31 characters, we have a special sytem in the syntax of file names which needs longer names, and I really have too much long file names ... so I live with the problem by NOT moving/changing the root folder of my files in the catalogue (NOT using "Reset folder path") and I hope that I don't HAVE to move it until this problem is fixed. Or I will be in big trouble ... I already have the trouble when trying to be mobile with my laptop - and taking a copy of the catalogue and the data out of the office on an external hard drive and trying to work with the catalogue by reassigning the root folder with "Reset folder path" - this is simply NOT POSSIBLE without getting trouble (because I often need to use "Update folder now"). So I have to stay at home ... thank you Microsoft ...
Hello Microsoft - hello Anita - do you hear us???
Patrick - I just read this news:
http://www.infoworld.com/d/developer-world/microsoft-pares-expression-studio-suite-012?source=rss_infoworld_news
Expression Studio will come as version 3 without Expression Media - but will Expression Media be upgraded, too? They don't write it very clearly ... Perhaps we will have to pay for the next update to get this bug fixed?
Or pay for the next update and keep the bug? - By the way (I just experienced this again today with EM 2.0.2/SP2 and OS X 10.5.8):
The command "MAKE" - "Backup/CD-ROM" cuts long FOLDER names to 31 characters.
Example:
"4_FINALS_WEB_RGB_[not for printing!]"
will be something like:
"4_FINALS_WEB_RGB_[not for#8B684"
Long FILE names do work ...
:-((( Hello,
On make CD there is a known bug, and I've marked it as very important. In fact, we just sent a list to our director of bugs that really should be fixed in the current version, and it was on there.
Regards,
Anita- Hi Anita,
Thanks for the update. What about this bug (the one this thread is about)? Did that get sent in as well?
Larry - Hi Larry,
I couldn't reproduce the original issue for this thread in SP2.
Regards,
Anita Oakley - Hi Anita,
The original issue this thread is about is the same as the outlined and fully reproducible bug as noted by p_horn above on Friday, June 12, 2009 12:51 PM .
Please report this very insidious bug to the tech team if you can, or let me know the appropriate place to submit it (again).
Thanks,
Larry - The CD issue has been reported.
What i could not reproduce was a problem moving the files and catalog to another server. - Anita,
p_horn established that this bug is not server/volume-related. So you won't always see the problem as I originally described it. He found a way to way to make it reproducible. It is fully reproducible on every configuration on every Mac I have (15+) using his steps. Please follow the steps he outlined in his post and note the discussion in the followup postings. It appears to only be file names that are affected, and quite severely! Creating a fresh catalog and re-importing files appears to have fixed the 31+ character folder name problem that persisted in catalogs from created from previous versions, but does not help with the file name problem.
Larry - The issue was reproduced after p_horn filed his bug on the Connect site, and I replied on 9/25.
Bugs have been filed for both the CD folder name and the long file name issues... That's all I can do.
Anita- Marked As Answer byAnita OakleyMSFT, ModeratorWednesday, November 04, 2009 4:39 PM
