BFile::SetTo returns inconsistent with R5

[anevilyak]

In R5, if you call BFile::SetTo(const char *path, uint mode) with a path to a file in which one of the subdirs does not exist, B_BAD_VALUE is returned. The same call in Haiku results in B_ENTRY_NOT_FOUND. This bug can be observed with the Vision IRC client, since its settings system relies on the B_BAD_VALUE return to determine whether or not the settings subdirectory needs to be created (it first tries to initialize a BFile to the path "/boot/home/config/settings/Vision/VisionSettings", and if this returns B_BAD_VALUE attempts to create the extra subdir needed). As a result, on Haiku the app never attempts to create the directory, and the attempt simply fails on the assumption that some other file creation error occurred.

[axeld]

It's never a good idea to check for a specific error code. The R5 behaviour is neither documented nor correct - ie. it doesn't match the documentation of either BFile::SetTo() nor open() (see ​http://www.opengroup.org/onlinepubs/009695399/toc.htm). Hence, I would suggest you fix that problem in Vision (since it's open source and all that) :-)

But thanks for the note - if we see that behaviour in a closed source application that's worth supporting, it might be worth duplicating the (IMO buggy) R5 behaviour. For now, I'm closing this bug, though.

[anevilyak]

In that case, how is one to distinguish between a failure due to some inability to create the file node, and a missing portion of the path? The whole reason I was checking that error code specifically was to avoid having to do create_directory unless necessary. None of the other documented returns allow this distinction.

[axeld]

That's right. You could either check the parent path, or just try to create the directory; it costs only a syscall (it doesn't do anything if the directory already exists), and it's definitely not a time critical operation.

[anevilyak]

Done, see ​http://www.bebits.com/bob/20932/Vision-0.9.7-SF-01052007.zip for updated version :)

[axeld]

Nice, thanks! :-)