Rockbox mail archiveSubject: Re: Re: Patch - virtual file structures
Re: Re: Patch - virtual file structures
From: TP Diffenbach <rockbox_at_diffenbach.org>
Date: Sun, 8 Jun 2003 21:37:24 -0400
I wrote some code (a set of API functions) to extract the real file name form an
MS Windows .lnk file, and posted it on this list.
I never integrated it into tree.c, but it could easily be done; you'd likely need
to add a new flag to the file_attr bitmap, and make some decisions on whether or
not to cache the real file name. If you did decide to cache it, you'd have to
either change the dir_cache structure, adding a char* not otherwise used, or a
klugde involving overloading the directory name. (E.g., if the first byte of a
name is (char)0, the next two bytes point to the real name, and the following
bytes to the nul terminator are the displayed name, or some such ugliness.)
Frankly, I'd use a second pointer, as I like seperating display name from real
name for other uses, but I'd understand the argument that this would be waste
space for users not using these new features.
There are some issues with copying .lnk files from the pc to the archos: relative
links will work, but absolute links don't work if the .lnk is copied as a normal
file, and it's not immediately clear why some .lnk files are absolute or relative.
Still, my experiements convinced me this could be overcome, just as Rockbox
overcomes it for .m3u files.
But the main argument against .lnk files is that each .lnk file is over 512 bytes
in length (to accomodate the file name), and closer to 1k, with overhead. As it's
a single file, it occupies at least the minimum disk cluster size, which on my
factory default jukebox is 16KB. 16,384 bytes, while small compared to an mp3, to
represent a single file still seems a mis-use of the limited space available on
I'd prefer to add playlist browsing, perhaps even "transparent" playlist browsing
along the line of Mr. Hoffman's patch.
If there is a general feeling on this list that .lnk files would be useful despite
the waste of space, I'd be happy to implement it -- let me know that you want it
by posting to the list.
Whatever the solution is, I think the next major addition to Rockbox needs to be
alternative directory structures of some sort.
Quoting Eric Linenberg <elinenbe_at_umich.edu>:
> What I don't understand is the reason behind creating our own format?
> What about windows shortcut format, or the symbolic link in unix/linux?
> MOQ> On Mon, 9 Jun 2003, BlueChip wrote:
> >> >>Isn't that better done with playlists?
> >> >I think the interesting part is not so much the playing as the
> >> >browsing through an arbitrary directory hierarchy. I was thinking
> >> >primarily of something similar to winamp's media library, or itunes,
> >> >one could locate a file by artist, genre, mood, or whatever.
> >> Get's my vote - I would love to have virtual dirs so that (for example)
> >> Fleetwood Mac turn up under both "Blues" and "Fleetwood Mac" ..also.. each
> >> compilation album would have it's files also show up under the specific
> >> I suppose its just a matter of whether you can see this new feature as an
> >> improvement, or if you prefers to stick to old ways because they are
> MOQ> One thing that would make this a lot more attractive would be an easy to
> MOQ> use too for creating the virtual dir files. I'm thinking of a tool (on
> MOQ> WinDoze box and/or Mac) that would scan the .mp3 files, and create the
> MOQ> virtual dirs based on the ID3 tags.
> MOQ> Now THAT would be powerful.
> MOQ> I don't really see how this idea of virtual dirs will be very exciting
> MOQ> without some sort of automated tool to create them. At last check, I
> MOQ> slightly over 8600 song on my Player -- way too many to catalog by hand.
> MOQ> I do make sure that each and every ID3 tag is correct before I copy it
> MOQ> to the Player, so an automated scan would certainly make sense for me.
> MOQ> Michael
-- Archos FM has a Rockbox!Received on 2003-06-09