Opened 12 years ago

Closed 12 years ago

Last modified 12 years ago

#1197 closed bug (invalid)

BFile::SetTo returns inconsistent with R5

Reported by: anevilyak Owned by: axeld
Priority: normal Milestone: R1
Component: Kits/Storage Kit Version: R1/pre-alpha1
Keywords: Cc: umccullough
Blocked By: Blocking:
Has a Patch: no Platform: All

Description

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.

Change History (6)

comment:1 Changed 12 years ago by umccullough

Cc: umccullough added

comment:2 Changed 12 years ago by axeld

Resolution: invalid
Status: newclosed

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.

comment:3 Changed 12 years ago by 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.

comment:4 Changed 12 years ago by 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.

comment:5 Changed 12 years ago by anevilyak

comment:6 Changed 12 years ago by axeld

Nice, thanks! :-)

Note: See TracTickets for help on using tickets.