Bug 10361 - readdir() et al. sometimes return 8.3 filenames for files with wide characters in their name - need to expand to full name
: readdir() et al. sometimes return 8.3 filenames for files with wide character...
Status: CLOSED FIXED
Product: Logitech Media Server
Classification: Unclassified
Component: Scanner
: 7.4.0
: PC Windows XP
: P3 normal with 1 vote (vote)
: 7.4.0
Assigned To: Michael Herger
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-12-17 02:27 UTC by Michael Herger
Modified: 2009-10-05 14:32 UTC (History)
1 user (show)

See Also:
Category: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Herger 2008-12-17 02:27:34 UTC
see eg. bug 8196, bug 10009

some code is already in Slim::Control::Queries::readdirectory:

# display full name if we got a Windows 8.3 file name
if (Slim::Utils::OSDetect::isWindows() && $name =~ /~\d/) {
	my $n = File::Basename::basename( Win32::GetLongPathName($path) );
	$log->info("Expand short name returned by readdir() to full name: $name -> $n");
	$name = $n;
}


This should be moved to S::U::OS::Win32 and used when needed
Comment 1 James Richardson 2008-12-21 19:38:01 UTC
No assigned bugs with out target :)
Comment 2 Michael Herger 2008-12-28 10:19:15 UTC
Nothing we're going to change in 7.3.x before some "real" users report this issue.
Comment 3 APB 2009-01-06 20:19:30 UTC
(In reply to comment #2)
> Nothing we're going to change in 7.3.x before some "real" users report this
> issue.

What exactly constitutes a "real" user?
Comment 4 Michael Herger 2009-01-06 23:37:06 UTC
> What exactly constitutes a "real" user?

Your subscribing to this bug :-). When I reported this issue, I wasn't aware of the fact that we've already hit it in several places. 

But still I'm sorry: this is too big a change to make it in to 7.3. I'll try to come up with a solution for 7.4/8. Thanks for your understanding.

BTW: which bug refered you to this one?
Comment 5 APB 2009-01-07 00:56:12 UTC
I'm the person who opened 8196 8-).
Comment 6 Michael Herger 2009-01-08 03:44:43 UTC
change 24558 - create full file name from Windows' short version when guessing title from playlist name.
Comment 7 Michael Herger 2009-01-09 02:56:51 UTC
change 24591 - more Windows short file name fixes
- move file name expansion to S::Music::Info::fileName
- fix BMF (player, web, CLI)
- use full path instead of nothing to be displayed if file name can't be extracted (eg. Windows shortcut pointing to drive letter without path)
Comment 8 Moonbase 2009-01-09 07:27:58 UTC
Okay, I vote for this bug. Could I please be considered I "real" user in this case? ;-)

I still agree with Michael this is — in general — probably "lo pri" for the majority of the user base, EXCEPT in "Browse Music Folders". Also, we need to check what the MusicIP API expects!
Comment 9 Michael Herger 2009-01-13 01:44:21 UTC
Moonbase reported in http://forums.slimdevices.com/showthread.php?t=57900

- Short filenames still on the "Song Info" page. It could be argued
  to -leave- those as are, since "Location" is also a download link and
  using the long filename here might break something (?).
Comment 10 Michael Herger 2009-07-28 03:16:19 UTC
this should be fixed in 7.4. Let's open new bugs for every particular occurence of th issue if needed.
Comment 11 James Richardson 2009-10-05 14:32:11 UTC
This bug has been marked as fixed in the 7.4.0 release version of SqueezeBox Server!
    * SqueezeCenter: 28672
    * Squeezebox 2 and 3: 130
    * Transporter: 80
    * Receiver: 65
    * Boom: 50
    * Controller: 7790
    * Radio: 7790  

Please see the Release Notes for all the details: http://wiki.slimdevices.com/index.php/Release_Notes

If you haven't already, please download and install the new version from http://www.logitechsqueezebox.com/support/download-squeezebox-server.html

If you are still experiencing this problem, feel free to reopen the bug with your new comments and we'll have another look.