Rockbox

That's an error in our code isnt it? My linux has . and .. in /.

If so, we should probably fix it. Otherwise we can undo that particular change and go back to HOME_DIR == "/" which is not entirely right IIUC (it can create paths starting with //). But that was before and worked, although amiconn noted that cygwin interprets // paths as network locations.

Windows also accepts \. even when it's a FAT32 partition, where . does not not actually exist in the root directory. I guess recognizing /. is a good thing. There's no other need for it, but consistency is good. It's a trivial change. This patch causes opendir_uncached() to recognize . as the current directory, without actually needing to search through the directory to find the . entry. It fixes the problems I described.

I don't like how /. is visible to the user, and how it uses up screen and memory space. Because of this concern, I was thinking about making HOME_DIR blank. The problem there is that opendir(HOME_DIR) won't work. This would currently only be a problem in create_numbered_filename(). It doesn't seem like there's any simple and elegant solution for removing the prefix.

Edit: With opendir_uncached_recognize_dot.patch, /./<volumename>/ is still broken, because it goes to the root file system instead of the volume. In strip_volume(), repeated / at the start are handled, but /./ isn't. Since strip_volume() is also used in open_internal(), it would have to be changed to handle this. I guess it doesn't matter though, because "/./<volumename>/" wouldn't happen. BTW Also .. is broken in connection with multivolume.

It may be best to use "/" for HOME_DIR. Rockbox can already handle //, and I don't see why Windows would ever be given paths starting with //.

RaaA can possibly pass "//"-paths to the OS.

wow this is the reason why I can't get recording and playlist to work on my fuze+. Desactiving cache is useful on fuze+ because of http://www.rockbox.org/tracker/task/12447?project=1&opened=6464

the patch solve the problem.

Why must it be static in nature? Couldn't "/" be used always and converted where necessary before accessing the hosts file system?

RaaA should do substitution for HOME_DIR. In both Unix-like environments and in Windows, writes to the root directory are undesirable. Stuff that belongs in HOME_DIR should go somewhere under the current user's home directory. Simply substituting HOME_DIR with the current user's home directory is ok, though respecting the desktop environment's documents and music folders is better. The function handling this could remove any extra unwanted prefix if necessary.

If it's too difficult to make "." and ".." work for the root I suggest changing HOME_DIR back to /, but I think create_*_filename in firmware/general.c need to be fixed to handle that (the comments say it doesn't handle trailing slashes).

create_*_filename() seems to work just fine with HOME_DIR set to "/". If no other proposal is committed during the next two days, I'll commit that.

Thanks for deciding to make the "/" change. It doensn't make sense to leave recording to the default directory broken to avoid problems which only happen in a configuration which doesn't currently exist. The "/" change is correct even if there's the intention of eventually doing something better.

Passing "/" to create_*_filename() works, though it creates filenames starting with "//". Recording replaces "/" with "" to avoid this. BTW This makes me think the following change in r31430 in create_numbered_filename() is wrong:
- dir = opendir(pathlen ? buffer : "/");
+ dir = opendir(pathlen ? buffer : HOME_DIR);
The code was probably there because passing "" as path is the proper way to create a filename in the root directory. Also, in r31430 the caller passes HOME_DIR, so either the defaulting to HOME_DIR or the passing of HOME_DIR is redundant.

It would be easy to change create_*_filename() to not create paths with "//" in the result. However, not much is gained as long as the preprocessor elsewhere creates paths starting with "//".

Would it be okay to have HOME_DIR end with a slash instead of appended things starting with a slash? This will certainly work if something is being appended. Also, our directory functions should work because strtok_r() will cause trailing slashes to be ignored. I just don't know if any other operating system requires that paths passed to directory functions not have a trailing slash.

I'm attaching code for more fully supporting "." and "..". Remaining issues and limitations are described below. Note that it's possible to test HAVE_MULTIVOLUME by shrinking the main FAT32 partition and creating another partition.

In opendir_uncached(), the parent directory passed to fat_opendir() is wrong after "..". It only seems to cause a problem in an unlikely rmdir() race condition. For more info, read the FIXME comment.

The _dircache_get_entry_volume() function nicely matches the API, but it does an extra dircache traverse from the entry toward the root. I think it's ok because the traverse is cheap. Otherwise, dircache_get_entry() would have to be changed to return the volume.

I did not fix strip_volume(). It's now only used in generate_bookmark_file_name().

In playlist_save(), strncmp() is used to check if the current playlist is being overwritten. That will fail if the playlist is being overwritten using a different path. I did not search for similar path comparisons elsewhere.

The last two could be solved by a function which creates a canonical file name, similar to POSIX realpath(). Adding more disk access seems like a bad idea, so it should probably be done via string manipulation. This could also replace the dircache changes. Accepting "/nonexistent/path/../../real/path/" is okay, because it would fail elsewhere. If succeeding with such paths is okay, then such a function could even replace the opendir_uncached() changes.

Full support for . and .. would make it possible to simplify format_track_path() in playlist code.