[find_directory] B_USER_DATA_DIRECTORY is NULL

[Janus]

Calling the find_directory function with directory_wich set to B_USER_DATA_DIRECTORY return NULL

[Janus]

Very strange exists a B_USER_NONPACKAGED_DATA_DIRECTORY I think it shouldn't. Even that directory return NULL.

[humdinger]

B_USER_DATA_DIRECTORY should return /boot/home/config/data...

I wonder why there's no B_USER_APPS_DIRECTORY and some others.

[humdinger]

I meant B_USER_NONPACKAGED_APPS_DIRECTORY in the above comment...

[Janus]

In the irc jessicah has pointed out that the command finddir works as expected with B_USER_DATA_DIRECTORY. I have investigated the problem and the different behavior between terminal and applications is very simple to explain. The command calls the function with the parameter createIt sets to false, the applications with the parameter sets to true, the directory /boot/home/config/data doesn't exist and the directory /boot/home/config is read-only.

This should explain why the function doesn't work.

[Janus]

Add

AddDirectoryToHaikuImage home config data ;

to /haiku/build/jam/images/definitions/common-tail

Should do the trick. I hope.

[Janus]

Shall we remove the directory_wich B_USER_NONPACKAGED_DATA_DIRECTORY?

[jessicah]

I think what we probably need to do is investigate changing the behaviour of our constants.

E.g. constants like B_USER_DATA_DIRECTORY point to the non-packaged locations, and use B_USER_PACKAGED_DATA_DIRECTORY instead. We'd probably want to maintain the B_USER_NONPACKAGED_DATA_DIRECTORY as a synonym for B_USER_DATA_DIRECTORY.

The defaults are currently somewhat backwards, in that you end up with read-only locations by default, which would also be a problem for BeOS binary compatibility, IMO.

[Janus]

Replying to Jessica:

I think what we probably need to do is investigate changing the behaviour of our constants.

I agree.

E.g. constants like B_USER_DATA_DIRECTORY point to the non-packaged locations, and use B_USER_PACKAGED_DATA_DIRECTORY instead. We'd probably want to maintain the B_USER_NONPACKAGED_DATA_DIRECTORY as a synonym for B_USER_DATA_DIRECTORY.

I don't know because when I think to the NONPACKAGED structure I think to something used for backward compatibility. In the future I hope all the new applications will use the packaged structure. So B_USER_PACKAGED_DATA_DIRECTORY should not exist.

The defaults are currently somewhat backwards, in that you end up with read-only locations by default, which would also be a problem for BeOS binary compatibility, IMO.

B_USER_DATA_DIRECTORY is not read only his parents is read only. It is the same for B_USER_SETTINGS_DIRECTORY. The problem is nobody has added this directory to the config directory.

[pulkomandy]

The correct way to handle this is to use BPathFinder / find_path, which use a different set of constants (B_FIND_PATH_*, defined in ​https://git.haiku-os.org/haiku/tree/headers/os/storage/FindDirectory.h#n134). The whole find_directory API will be deprecated at some point (likely in R2, and then removed in R3?).

We should write docs for BPathFinder, however!

Also, BeOS didn't have a B_USER_DATA_DIRECTORY, so I wonder how we could hit a binary compatibility problem there: ​https://github.com/jscipione/r5headers/blob/master/headers/be/storage/FindDirectory.h (that may still apply to other directories, however).

[Janus]

The problem persists with BPathFinder. The directory /boot/home/config/data doesn't exist and /boot/home/config/ is readonly...

So even with BPathFinder is impossible to access the B_FIND_PATH_DATA_DIRECTORY.

To fix this we must create the directory as explained in comment:5

[pulkomandy]

Yes, indeed. I was just referring to Jessica's comment that the find_directory constants should be changed.

However, what would be the point of creating an empty directory where no one can write? If some software bundles data, it will comme with its own data directory in the package, and then if it uses BPathFinder or find_directory, it will find it. Otherwise, the directory is not used, and there is no point in creating it.