I got an API question regarding directories - I want to recursively delete a directory (it’s just in temp and managed by my App, so I don’t care about the contents, I always need to create that structure afresh).
There is a create_directory() to create a directory with all intermediate dirs if necessary, but there is no matching remove_directory. There is only the VFS remove_dir which chokes on existing subdirs…
Since this is quite a common standard operation, I would really suggest to add this to the Haiku API as a utility function if it is not already there and I missed it somehow.
I’d rather not bother with a manual implementation if I can avoid it.
You can use the c++ standard function std::filesystem::remove_all(). Since c++ now has standard functions for this, there is less need to hrovide haiku specific ones, I think?
wow didn’t know that one.
However, as we like to keep the API consistent and symmetric in other occasions, I think a Haiku native wrapper would be really nice.
The same could be said for B(Object)List, BString,… (ok that’s for compatibility reasons, I get it, but still…).
Personally, I think that a filesystem library is a rather bizarre thing to be including in the standard libraries of a programming language which might ostensibly be used under any operating system and with different filesystems.
I’m also not sure if it is wise to have such a tight dependency on something that might get changed in the future…
Does Haiku also use other parts of std::filesystem like the C++ standard function std::filesystem::create_directory(…) to create a directory? And if not, wouldn’t consistency be preferable over haphazard use of both haiku specific functions and ones coming from the C++ standard library.
Besides, using std library has a viral effect as it requires you to use other classes and that draws in a lot of C++ library dependencies you want to avoid.
E.g. in this case, I need to use std::filesystem::path although I have a native BPath already, not good.
I’ll open a feature request because ths is really not good and needs to be fixed.
If we go down that road, we might as well switch to Qt entirely and use Be/Haiku wrappers for everything…
PS: in other places, we keep backwards compatibility as much as possible, but this C++ API was only added in C++ 17…
The C++ standard library is there with the compiler anyways. Replicating its functionality in libbe adds duplicate code for no to little win. I would rather improve interoperability between the legagy BPath and the standard std::filesystem::path. And if we want to add an API in BPath, it makes sense to implement it using the C++ standard library and not roll our own thing?
Qt is not shipped with the compiler, as far as I know.
But let’s suppose that someone wants to create hooks to the Haiku API for their favourite language. Swift, Vala, Rust, whatever the hot new language of the moment is. ATM all we have is yab. I know people are working on Python, but I haven’t seen much from them recently.
I imagine all those languages have their own directory deleting functions and if they don’t, you can always make a system call, but it would just be more … elegant if it could all be done via Haiku.
I know, it’s not a major consideraton. That’s never stopped me before, though.
If there were Python bindings for Haiku and I was to use them, surely I would use Python native APIs to manage paths and files. Why would I bother handling foreign BDirectory objects that just make things harder to use and feel alien to the language?
The BPath class only exists to bridge a gap that existed in the C++ specification 30 years ago. This gap has since been filled. There’s no need to keep the old solution forever.
That’s not the case for many other classes. For example BString and std::string are quite different in their approach. BObjectList is not the same as the std containers. The interface kit has no alternative at all, and if it ever gets one, it will probably be so different that we may not implement it at all, and keep what we have.
Support for networked objects is easily gained by adding filesystems for them. The API doesn’t need to ghange in any way for that.
I would strongly prefer this approach to whatever Linux is doing, where some apps use the “right” API and you can access an smb:// link with them. But then another app just uses regular fopen, and you can’t use the same path with it.
Please don’t repeat that mistake.
I’m not sure woat I would change in the existing API, the documentation could be improved, but the API itself seems quite good to me…
Some good points @PulkoMandy, however I still think the Haiku API should stand on its own feet and not selectively rely on C++ “standard” features (better than in the old days but still not part of the native API).
The reason in this case being the prominent and special case of the BFS with all its metadata glory and indexed attributes, queries etc.
Since we rely on Haiku’s filesystem API anyway, it feels awkward having to fall back to C++ functions that depend on yet more C++ types not present in the Haiku API.
It just feels tacked on and not uniform to me.
Having said that, using the C++ function worked instantly as expected.
I understand the annoyance but disagree with your analysis, ideally there should be one api, and that should have the equivalent of a uri. Having to mount filesystems at a specific path and that having to be unique to the filesystem and conflicting if you need severall views (like multiple smb credentials) is super annoying and seems like a major design flaw to me.
Plan 9 already fixed this, so no I don’t think we should neccesarily keep just whatever unix did… but keep in mind that I expect the timescale for whenever this api would be revisited to be for R2, and not changed majorly during the R1 release cycle.
In UNIX and POSIX, everything is a file. This means you have to mount things in the filesystem if you want to use them with all APIs consistently. This is exactly what plan9 did.
Maybe you can do fancy things and allow some file paths to start with ‘http:’ instead of ‘/http/’, but that doesn’t change the underlying implementation. If you want to handle things as files, you have to handle them using a filesystem.
Having to mount filesystems at a specific path and that having to be unique to the filesystem and conflicting if you need severall views (like multiple smb credentials) is super annoying and seems like a major design flaw to me.
What is the difference between mounting at /smb/… and smb://… ? I see none. Just a different naming convention and an extra level of namespacing above paths. If anything, using an URL like smb:// forces you to put all your SMB mounts in the same namespace (they all must start with smb:// followed by a host name), whereas mount points allow you to mount things anywhere you want.
In Linux, the “fake” smb:// URL actually resolves to /var/run/gvfs/1000/something/. And so this could have simply been implemented by using that path directly, and it would have worked fine in all existing apps and command line tools. But they chose to hide this path and make it hard to access for apps not using gvfs.
The difference (to us) is a usb drive named “smb” that mounts to the same directory. The point is that in the plan9 model the view you get is different per application, so your smb://server/share/file can be retrieved with a different server connection and credentials as opposed to the same one because it is the same mountpoint.
This sounds very confusing. It means I cannot ever copy-paste or drag and drop a file path from one application to another? I do that all the time, dropping things in terminal to get their paths added to a command line, or dropping a file I have visible in tracker into some application filepanel.
And when I monunt a disk, everyone can access it, not just one app.
It is already existing practice for applications running in containers/namespaces. Linux promote this for GUI applications too. It is useful for permissions management so some random program will not have access to your sensitive data.
No, it does not mean that. It’s simply a different model of working (and defaults).
Drag & Drop can negotiate the file directly, it does not need to go back to a path or anything like that. Similarily a file picker will give the app a handle to the file directly, instead of telling it a location (which might also have racily changed in the meantime)
So essentially it replaces an easy to understand “permission denied” error with a “no such file or directory” one?
Please explain how that works in my example of drag and dropping a file to Terminal. Or any app that doesn’t use the “new” API and works with files.
This allows to escape permission checks on the file path. In UNIX, you can’t access a file if you can’t also access its parent directory. Now it would be trivial to escape that as long as you have the inode number. And anyway, in the end you still need a central database of files and where they are located. Why not use the perfectly good hierarchical filesystem for that? It’s simple to understand. Making it different for each app just add a whole new layer of confusion. Essentially you have to completely forget about paths and organizing your files, since apps will not be able to access them this way. You all work with inode numbers, or at best, just filenames.
This looks very much like the way iOS and Android do things as well. It just gets in the way of working with the same file in different apps, and I don’t see any gain from it.
