Filesystem Library and Standardized Paths

[Jens Åkerblom]

Hello there,

I've been looking through the proposed C++17 Filesystem library and thought it would be a nice add-on to have common paths. The only path I see that is already present is the std::filesystem::temp_directory_path. The directories of interest (as I see) would be

• executable_directory_path, installed_directory_path or maybe a better name, bundle_directory_path, directory where the executable is being run / has been installed. Assumed to be read-only.
  
• userdata_directory_path, directory where current user stores data, "My Documents" on Windows for example. Assume permission required to write and read.
  
• cache_directory_path, directory to data that persists longer than in temp_diretory_path, can be removed by OS if deemed necessary. "Library/Cache" on iOS for example. Assume write and read permission.
  
• appdata_directory_path, directory where the application can store persistent data not to be shared with other application. "/data/data/<package_name>" on Android for example. Assume write and read permissions.
  

I'm sure there are plenty of other common useful paths you can think of in addition to the above.

Is there anything like this already proposed and / or rejected? If not, do you think this would be a good extension to the Filesystem Library?

[Nicol Bolas]

On Sunday, September 11, 2016 at 11:19:35 AM UTC-4, Jens Åkerblom wrote:

Hello there,

I've been looking through the proposed C++17 Filesystem library and thought it would be a nice add-on to have common paths. The only path I see that is already present is the std::filesystem::temp_directory_path. The directories of interest (as I see) would be

• executable_directory_path, installed_directory_path or maybe a better name, bundle_directory_path, directory where the executable is being run / has been installed. Assumed to be read-only.
  

This should not just be a directory path; it should include the name of the executable as well. If you want the directory, just clip off the executable. While `argv[0]` works on some platforms, it doesn't work on UTF-16 platforms. This would give us a standard way to get at the executable file path.

• 
  
• userdata_directory_path, directory where current user stores data, "My Documents" on Windows for example. Assume permission required to write and read.
• cache_directory_path, directory to data that persists longer than in temp_diretory_path, can be removed by OS if deemed necessary. "Library/Cache" on iOS for example. Assume write and read permission.
  
• appdata_directory_path, directory where the application can store persistent data not to be shared with other application. "/data/data/<package_name>" on Android for example. Assume write and read permissions.
  

I don't like `temp_directory_path` as is, so I don't want to see a proliferation of similar platform-specific directories.

[Matthew Woehlke]

On 2016-09-11 11:19, Jens Åkerblom wrote:
> Hello there,
>
> I've been looking through the proposed C++17 Filesystem library and thought
> it would be a nice add-on to have common paths. The only path I see that is

> already present is the *std::filesystem::temp_directory_path*. The

> directories of interest (as I see) would be
>

> - *executable_directory_path*, *installed_directory_path* or maybe a
> better name, *bundle_directory_path*, directory where the executable is

> being run / has been installed. Assumed to be read-only.

I don't think you can implement this without platform support. That
support *might* already be available on common platforms, but then again
it might not.

Implementing it for example on Linux requires digging around in /proc.
Specifically, you need something like https://github.com/gpakosz/whereami.

> - *userdata_directory_path*, directory where current user stores data,

> "My Documents" on Windows for example. Assume permission required to write
> and read.

> - *cache_directory_path*, directory to data that persists longer than in
> *temp_diretory_path*, can be removed by OS if deemed necessary.

> "Library/Cache" on iOS for example. Assume write and read permission.

> - *appdata_directory_path*, directory where the application can store

> persistent data not to be shared with other application.
> "/data/data/<package_name>" on Android for example. Assume write and read
> permissions.

These may be simplifications. I would compare with existing prior art,
e.g. http://doc.qt.io/qt-5/qstandardpaths.html.

--
Matthew

[Jens Åkerblom]

These may be simplifications. I would compare with existing prior art,
e.g. http://doc.qt.io/qt-5/qstandardpaths.html.

Thank you for the QStandardPaths link, did not know that existed. This is exactly what I'm hoping would end up in the standard (or at least some of the paths). As I see it, any file operations in C++ must either use current_path() or do their own platform dependent path lookup (or use third party libraries to do it for them). Shifting the responsibility to write these path lookups to the standard library writers would thus make it easier to write platform independent code in my opinion.

Do you think this is worth taking forward by writing a proper proposal?

[Bo Persson]

On 2016-09-20 10:25, Jens Åkerblom wrote:
> These may be simplifications. I would compare with existing prior art,
> e.g. http://doc.qt.io/qt-5/qstandardpaths.html

> <http://doc.qt.io/qt-5/qstandardpaths.html>.

>
>
> Thank you for the QStandardPaths link, did not know that existed. This
> is exactly what I'm hoping would end up in the standard (or at least
> some of the paths). As I see it, any file operations in C++ must either
> use current_path() or do their own platform dependent path lookup (or
> use third party libraries to do it for them). Shifting the
> responsibility to write these path lookups to the standard library
> writers would thus make it easier to write platform independent code in
> my opinion.

The portability of programs using items like DesktopLocation will still
be limited to systems actually having a desktop. And using paths.

>
> Do you think this is worth taking forward by writing a proper proposal?

Possibly.

But it is not a total advantage to have too many features
"conditionally-supported with implementation-defined behavior". Because
the perceived increased portabilty can become a new problem if only one
or two systems actually support all the features.


Bo Persson