Rockbox.org home
release
dev builds
extras
themes manual
wiki
device status forums
mailing lists
IRC bugs
patches
dev guide



Rockbox mail archive

Subject: Re: Patch - virtual file structures

Re: Patch - virtual file structures

From: Owen Sebastian Hofmann <oshofmann_at_amherst.edu>
Date: Sun, 08 Jun 2003 22:20:25 -0400

TP Diffenbach wrote:
> 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
> the jukebox.
>
> 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.
>
> --Tom

Like you say, there are arguments for and against .lnk files. I like
the fact that it's dead easy for windows users to create them, but they
do have icky overhead, and linux users are left in the dust without some
tool for creating them. I think it would be useful, and I don't think
it would take up too much space. I think the filename shouldn't have to
be cached, since when you want to play something, you're spinning up the
disk to play it anyways.
Received on 2003-06-09

Page template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy