# GSoC '25: stdlib filesystem **URL:** \ **Category:** GSoC-2025\ **Created:** [May 26, 2025, 5:02pm UTC](https://fortran-lang.discourse.group/t/gsoc-25-stdlib-filesystem/9798 "2025-05-26T17:02:23Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![suprit05](https://avatars.discourse-cdn.com/v4/letter/s/e5b9ba/32.png) [@suprit05](https://fortran-lang.discourse.group/u/suprit05)\ **Post date:** [May 26, 2025, 5:02pm UTC](https://fortran-lang.discourse.group/t/gsoc-25-stdlib-filesystem/9798/1 "2025-05-26T17:02:23Z")
Hello everyone! As you may be aware I have been accepted in this year’s [GSoC](https://summerofcode.withgoogle.com/programs/2025/projects/xTdyYrMf) under the mentorship of @hkvzjal and @fxm. I will be giving weekly updates in this thread with it’s relevant PR’s, discussions etc The initial plan is to start with implementing some `path` functions useful for further functionality taking inspiration from [stdlib\_os](https://github.com/MarDiehl/stdlib_os)’s `os_path` module developed by @MarDie, @Arjen and @awvwgk and from how other languages like Python, Go, Rust etc handle it. If you have any feedback, suggestions, questions etc do let me know! Thank you! ---
**Author:** ![fxm](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/fxm/32/5726_2.png) [@fxm](https://fortran-lang.discourse.group/u/fxm)\ **Post date:** [May 26, 2025, 5:11pm UTC](https://fortran-lang.discourse.group/t/gsoc-25-stdlib-filesystem/9798/2 "2025-05-26T17:11:41Z")
Thanks for starting this, @suprit05. I’m tagging @FedericoPerini here as another mentor, who - alongside Jose - has a much deeper understanding of stdlib itself. 🙂 ---
**Author:** ![urbanjost](https://avatars.discourse-cdn.com/v4/letter/u/0ea827/32.png) [@urbanjost](https://fortran-lang.discourse.group/u/urbanjost)\ **Post date:** [May 26, 2025, 10:56pm UTC](https://fortran-lang.discourse.group/t/gsoc-25-stdlib-filesystem/9798/3 "2025-05-26T22:56:51Z")
Additional resources that might be of interest are - the [Fortran Wiki](https://fortranwiki.org). In particular, look under **System** in the [library listings](https://fortranwiki.org/fortran/show/Libraries). - Then there is [Beliavskys’ List](https://github.com/Beliavsky/Fortran-code-on-GitHub?tab=readme-ov-file#file-io) with perhaps the most extensive list of I/O libraries. - My **personal favorites** are 1. [M\_io](https://github.com/urbanjost/M_io) 2. [M\_path](https://github.com/urbanjost/M_path) 3. [M\_process](https://github.com/urbanjost/M_process) 4. [M\_system](https://github.com/urbanjost/M_system) 😄. I listed mine in probable order of relevance, but just guessing. There are others perhaps others can list. Some interesting differences in OOP versus procedural, how different platforms are distinguished, how proprocessing is applied, whether ford or doxygen is used, documentation approaches in general, … ---
**Author:** ![davidpfister](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/davidpfister/32/3949_2.png) [@davidpfister](https://fortran-lang.discourse.group/u/davidpfister)\ **Post date:** [May 28, 2025, 7:05am UTC](https://fortran-lang.discourse.group/t/gsoc-25-stdlib-filesystem/9798/4 "2025-05-28T07:05:07Z")
If you plan to include support for files and directories you may also want to have a look at what @interkosmos did with [fortran-unix](https://github.com/interkosmos/fortran-unix/) and in particular the binding to [dirent](https://github.com/interkosmos/fortran-unix/blob/master/src/unix_dirent.F90). It is not portable to Windows but you can make it so with that [dirent.h](https://github.com/tronkko/dirent/blob/master/include/dirent.h) header. Just some food for thoughts for your `path` functionality. When working with [Nuke](https://github.com/nuke-build/nuke) (in C#) I came across their [AbsolutePath](https://github.com/nuke-build/nuke/blob/develop/source/Nuke.Utilities/IO/AbsolutePath.cs) (resp. RelativePath) object which I found very convenient. In brief, it overloads the `/` operator so that you can build paths in a very visual way (e.g. `newpath = root / folder / filename`) and the operator takes care of choosing `/` or `\` depending on the os and does the proper file concatenation. ---
**Author:** ![rgba](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/rgba/32/2115_2.png) [@rgba](https://fortran-lang.discourse.group/u/rgba)\ **Post date:** [June 6, 2025, 4:43am UTC](https://fortran-lang.discourse.group/t/gsoc-25-stdlib-filesystem/9798/5 "2025-06-06T04:43:51Z")
This would really be amazing! ---
**Author:** ![jkd2022](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/jkd2022/32/1949_2.png) [@jkd2022](https://fortran-lang.discourse.group/u/jkd2022)\ **Post date:** [June 6, 2025, 1:08pm UTC](https://fortran-lang.discourse.group/t/gsoc-25-stdlib-filesystem/9798/6 "2025-06-06T13:08:00Z")
A welcome feature of any stdlib file system for use with HPC applications, would be a RAM disk implemented as a fixed directory. For example, we could open a file like: ```auto open(60,file='/stdlib_fs/file.txt',form='FORMATTED') ``` with the directory `/stdlib_fs` looking like that of a normal file system but existing in volatile memory only. This is important for HPC systems where the networked file system can be a severe bottleneck. In fact, we implement a simple version of this in our code for direct access files only. Here’s a snippet: ```auto ! construct the filename fname=trim(scrpath)//'EVECSV'//trim(fext) !$OMP CRITICAL(u206) ! read from RAM disk if required if (ramdisk) then call getrd(fname,ik,tgs,v1=vkl_,n1=nstsv_,nzv=nstsv*nstsv,zva=evecsv) if (tgs) goto 10 end if ! find the record length inquire(iolength=recl) vkl_,nstsv_,evecsv open(206,file=fname,form='UNFORMATTED',access='DIRECT',recl=recl) read(206,rec=ik) vkl_,nstsv_,evecsv close(206) 10 continue !$OMP END CRITICAL(u206) ``` In this case, if `ramdisk` is `.true`. then the data will be retrieved from memory unless the data is not in the RAM disk, in which case the code will fall back to the normal file system. Simple as this is, it allows for almost ideal scaling as more nodes are added, which is not the case with the networked file system, which can result in longer run times with increasing node count. To be particularly useful, `/stdlib_fs` would have to be visible to, and consistent among different nodes on a cluster. This would be fairly difficult to implement (probably using MPI) and our simple RAM disk does not do this. [However, it could likely be done at a system level using [BeeGFS On Demand](https://doc.beegfs.io/latest/advanced_topics/beeond.html) which is an on-the-fly parallel file system. Used in combination with the Linux RAM disk in `tmpfs`, a RAM-only parallel file system could be generated for the running application only, avoiding having to access the shared file system.] ---
**Author:** ![suprit05](https://avatars.discourse-cdn.com/v4/letter/s/e5b9ba/32.png) [@suprit05](https://fortran-lang.discourse.group/u/suprit05)\ **Post date:** [June 18, 2025, 2:35pm UTC](https://fortran-lang.discourse.group/t/gsoc-25-stdlib-filesystem/9798/7 "2025-06-18T14:35:55Z")
**Progress Update: as of 17th June 2024** Goal was to start with implementing `path` related functions to facilitate future addition of functionality. **Pull Requests** - [`stdlib_system`: essential path functionality by wassup05 · Pull Request #999 · fortran-lang/stdlib · GitHub](https://github.com/fortran-lang/stdlib/pull/999) Basic path related functions were added. `joinpath`: joins the given paths according to the platform’s `path-separator`. `operator(/)`: as was suggested in the discourse [here](https://fortran-lang.discourse.group/t/gsoc-25-stdlib-filesystem/9798/4) by @davidpfister an operator is also provided for the same functionality `splitpath`: splits the path following the last `path-separator` and returns the `head` and `tail`. `basename`: just returns the `tail` returned `splitpath` `dirname`: just returns the `head` returned by `splitpath` Build system adjustments were also made to add some compile time constants according to the platform. - [feat: filesystem error handling by wassup05 · Pull Request #1006 · fortran-lang/stdlib · GitHub](https://github.com/fortran-lang/stdlib/pull/1006) A derived type `fs_error` containg an integer `code` and a fixed-length string is added for concise error handling This is a stripped down version of `state_type` already present in the `stdlib`, syntax is also kept very similar… except the introduction of `code` to store integers returned by C functions such as `GetLastError` (Windows API), global variables like `errno` (Posix platforms) _All PRs are accompanied by their relevant tests, documentation and examples_ **Concepts Learnt** How different operating systems handle error handling, system calls, backward compatibility, legacy code etc Mostly learnt by reading code of already existing fileystem libraries like - [os.path — Common pathname manipulations — Python 3.13.5 documentation](https://docs.python.org/3/library/os.path.html) - [os — Miscellaneous operating system interfaces — Python 3.13.5 documentation](https://docs.python.org/3/library/os.html) - [filepath package - path/filepath - Go Packages](https://pkg.go.dev/path/filepath) - [os package - os - Go Packages](https://pkg.go.dev/os) And of course `man` pages and Windows API documentation 😀 . ---
**Author:** ![PierU](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/pieru/32/1848_2.png) [@PierU](https://fortran-lang.discourse.group/u/PierU)\ **Post date:** [June 18, 2025, 3:36pm UTC](https://fortran-lang.discourse.group/t/gsoc-25-stdlib-filesystem/9798/8 "2025-06-18T15:36:13Z")
> [@jkd2022](#): > > A welcome feature of any stdlib file system for use with HPC applications, would be a RAM disk implemented as a fixed directory. > > For example, we could open a file like: > > ```auto > open(60,file='/stdlib_fs/file.txt',form='FORMATTED') > > ``` > > with the directory `/stdlib_fs` looking like that of a normal file system but existing in volatile memory only. I don’t really get it: a ramdisk is typically an OS feature, and once a ramdisk is created on the machine, it can be transparently accessed by any application as if it was a regular disk. > [@jkd2022](#): > > This is important for HPC systems where the networked file system can be a severe bottleneck. HPC systems often have local disks (preferably SSD, nowadays) on the nodes. ---
**Author:** ![jkd2022](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/jkd2022/32/1949_2.png) [@jkd2022](https://fortran-lang.discourse.group/u/jkd2022)\ **Post date:** [June 18, 2025, 10:02pm UTC](https://fortran-lang.discourse.group/t/gsoc-25-stdlib-filesystem/9798/9 "2025-06-18T22:02:44Z")
> @PierU: > I don’t really get it: a ramdisk is typically an OS feature, and once a ramdisk is created on the machine, it can be transparently accessed by any application as if it was a regular disk. Setting up a RAM disk may not be possible on a cluster with user privileges only. > @PierU > HPC systems often have local disks (preferably SSD, nowadays) on the nodes. How does Node A read the SSD of Node B? This is what [BeeGFS On Demand](https://doc.beegfs.io/latest/advanced_topics/beeond.html) was made for, it can link the disks of separate nodes together into a concurrent parallel filesystem, which is made available only for the running application. However root privileges are required to set it up. For our code we have data which should preserved between runs and available to all nodes during runs. Our simple ‘RAM disk’ stores only the data generated by that node, and defaults to the regular file system for off-node data. ---
**Author:** ![rwmsu](https://avatars.discourse-cdn.com/v4/letter/r/48db29/32.png) [@rwmsu](https://fortran-lang.discourse.group/u/rwmsu)\ **Post date:** [June 18, 2025, 10:13pm UTC](https://fortran-lang.discourse.group/t/gsoc-25-stdlib-filesystem/9798/10 "2025-06-18T22:13:51Z")
All the HPC systems I’ve used in the last 15 or so years used the [LUSTRE file system](https://www.lustre.org/) for programs running on the backend compute nodes. If I remeber how LUSTRE works you write data to a cluster of meta-data servers which then figures out the best way to “stripe” your data to the final storage disks. ---
**Author:** ![RonShepard](https://avatars.discourse-cdn.com/v4/letter/r/a3d4f5/32.png) [@RonShepard](https://fortran-lang.discourse.group/u/RonShepard)\ **Post date:** [June 18, 2025, 10:29pm UTC](https://fortran-lang.discourse.group/t/gsoc-25-stdlib-filesystem/9798/11 "2025-06-18T22:29:31Z")
It seems like there are two different features being discussed as if they are the same thing. The OP specified a ram disk where data could be accessed with i/o statements, yet it lived in volatile memory. Volatile memory implies memory just during a single program execution step. But the important feature of a ram disk is that it persists beyond a single program execution step so that it can be accessed not only by a running program but also other programs running at the same time or other programs running at some later time. The data is placed in ram memory presumably to enhance bandwidth or reduce latency compared to, for example, a physical spinning hard disk. If the shared data is intended to exist only within the lifetime of an executing program, including a parallel program running on multiple threads or multiple nodes, then other options are available, including data within a shared module or data accessed on remote nodes by MPI or with coarrays. But if the data is intended to persist over the lifetimes of several program execution steps, then MPI or corarrays are insufficient. ---
**Author:** ![PierU](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/pieru/32/1848_2.png) [@PierU](https://fortran-lang.discourse.group/u/PierU)\ **Post date:** [June 19, 2025, 5:40am UTC](https://fortran-lang.discourse.group/t/gsoc-25-stdlib-filesystem/9798/12 "2025-06-19T05:40:16Z")
> [@jkd2022](#): > > How does Node A read the SSD of Node B? This is what [BeeGFS On Demand](https://doc.beegfs.io/latest/advanced_topics/beeond.html) was made for, it can link the disks of separate nodes together into a concurrent parallel filesystem, which is made available only for the running application. However root privileges are required to set it up. So there are 2 fully orthogonal topics: - setting up and using a ramdisk; yes, setting up the ramdisk requires root privileges at some point, and I can’t see how a regular user process can create it on-the-fly (which was your initial wish) - setting up a shared FS between nodes, which is what BeeGFS does. As mentioned in the description, it uses existing local disks -including ramdisks- to create a shared FS, but it won’t create a ramdisk on its own. At the end I can’t really see what may be added in stdlib here (?). ---
**Author:** ![davidpfister](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/davidpfister/32/3949_2.png) [@davidpfister](https://fortran-lang.discourse.group/u/davidpfister)\ **Post date:** [June 19, 2025, 7:26am UTC](https://fortran-lang.discourse.group/t/gsoc-25-stdlib-filesystem/9798/13 "2025-06-19T07:26:37Z")
Hi @suprit05, Good PR!, I had a look at it and I have few comments. I hope this is fine if I put them here. This is mostly about hardcoded `pathsep` in stdlib\_system. While the approach looks fine, you may want to have a look at the function [separator()](https://github.com/fortran-lang/fpm/blob/6908108f5f364ca50e36a01d935967954cdee23e/src/fpm_environment.f90#L289) in [fpm](https://github.com/fortran-lang/fpm/tree/main). I also noticed the comment `! if no pathsep, then it probably was a root dir like C:\`. That probably means that you need a function `isrooted` and `isabsolute`/`isrelative` (and eventually `fullpath`) General question here: would that make sense to unify [fpm\_filesystem](https://github.com/fortran-lang/fpm/blob/main/src/fpm_filesystem.F90) with the stdlib\_filesystem? Keep the good job 👍 ---
**Author:** ![hkvzjal](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/hkvzjal/32/3055_2.png) [@hkvzjal](https://fortran-lang.discourse.group/u/hkvzjal)\ **Post date:** [June 19, 2025, 7:56am UTC](https://fortran-lang.discourse.group/t/gsoc-25-stdlib-filesystem/9798/14 "2025-06-19T07:56:19Z")
> [@davidpfister](#): > > function [separator()](https://github.com/fortran-lang/fpm/blob/6908108f5f364ca50e36a01d935967954cdee23e/src/fpm_environment.f90#L289) in [fpm](https://github.com/fortran-lang/fpm/tree/main). I think that for stdlib, having the path separator as a compile-time constant instead of a function is the ideal approach. ---
**Author:** ![davidpfister](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/davidpfister/32/3949_2.png) [@davidpfister](https://fortran-lang.discourse.group/u/davidpfister)\ **Post date:** [June 19, 2025, 8:03am UTC](https://fortran-lang.discourse.group/t/gsoc-25-stdlib-filesystem/9798/15 "2025-06-19T08:03:13Z")
That’s definitely true if you compile stdlib with your project on the desired platform. This implicitly means that you do not plan to distribute stdlib as binaries for dynamic linking. That said, I do agree that calling a function every time you need to access the separator value is a bit heavy. This could only be done once and the result stored in a module variable. ---
**Author:** ![hkvzjal](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/hkvzjal/32/3055_2.png) [@hkvzjal](https://fortran-lang.discourse.group/u/hkvzjal)\ **Post date:** [June 19, 2025, 8:24am UTC](https://fortran-lang.discourse.group/t/gsoc-25-stdlib-filesystem/9798/16 "2025-06-19T08:24:59Z")
> [@davidpfister](#): > > This implicitly means that you do not plan to distribute stdlib as binaries for dynamic linking AFAIK, you can’t use a linux compiled shared library on windows nor the other way around. You can do cross-compilation with MinGW to use a linux kernel to produce a windows binary, but it is still a binary target for Windows. On Windows you’ll use a WSL but per the compiler and produced binary, it is a Linux kernel for any practical purposes. So I would say that this is not an actual problem since by default you have to produce your binaries per targeted platform in any case. ---
**Author:** ![FedericoPerini](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/federicoperini/32/1750_2.png) [@FedericoPerini](https://fortran-lang.discourse.group/u/FedericoPerini)\ **Post date:** [June 19, 2025, 8:50am UTC](https://fortran-lang.discourse.group/t/gsoc-25-stdlib-filesystem/9798/17 "2025-06-19T08:50:31Z")
> [@davidpfister](#): > > calling a function every time In Windows, you may be working in a non-cmd shell, i.e. a Git shell, or a MinGW shell, so `\` may not be the default separator under all circumstances ---
**Author:** ![davidpfister](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/davidpfister/32/3949_2.png) [@davidpfister](https://fortran-lang.discourse.group/u/davidpfister)\ **Post date:** [June 19, 2025, 12:30pm UTC](https://fortran-lang.discourse.group/t/gsoc-25-stdlib-filesystem/9798/18 "2025-06-19T12:30:41Z")
> [@hkvzjal](#): > > compile-time constant Just another thing that came to my mind. AFAIK unlike ifort/ifx, gfortran does not define macros like `_WIN32` depending on the platform you compile on. So, if you use fpm as a build system you have to supply it in the toml file: ```toml [preprocess] cpp.suffixes = ["F90", "f90"] cpp.macros = ["_WIN32"] ``` which makes the fpm.toml platform-dependent, unless you use [profiles](https://fortran-lang.discourse.group/t/fpm-platform-specific-instructions-to-linker-on-fpm-toml/7296/13) as discussed here. ---
**Author:** ![hkvzjal](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/hkvzjal/32/3055_2.png) [@hkvzjal](https://fortran-lang.discourse.group/u/hkvzjal)\ **Post date:** [June 19, 2025, 12:52pm UTC](https://fortran-lang.discourse.group/t/gsoc-25-stdlib-filesystem/9798/19 "2025-06-19T12:52:02Z")
Since the introduction of file system stuff, stdlib also has a little bit of C baked inside, so maybe it can be resolved on the C files and the constant passed to the Fortran module? gcc does include all the necessary macros that gfortran doesn’t. ---
**Author:** ![jkd2022](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/jkd2022/32/1949_2.png) [@jkd2022](https://fortran-lang.discourse.group/u/jkd2022)\ **Post date:** [June 19, 2025, 8:27pm UTC](https://fortran-lang.discourse.group/t/gsoc-25-stdlib-filesystem/9798/20 "2025-06-19T20:27:14Z")
> @PierU > At the end I can’t really see what may be added in stdlib here (?). To demonstrate the effect of our toy ‘RAM disk’ I ran the same quantum time-evolution calculation on 16 nodes (4096 cores) of a 768 node cluster with a 20 PB parallel file system, shared by many other users. With our ‘RAM disk’ enabled and no writing of direct access files, the job took 21 minutes. The CPU utilization was over 90% Without using the ‘RAM disk’ the time was 87 minutes with a CPU utilization of about 40%. As you can see, the shared file system is a severe bottle-neck for our type of calculation, with CPUs having to wait for data to be written and read. This feature of a temporary, volatile file system could be made more general-purpose and part of stdlib. For example, there could be routines like ```auto open_stdlib(50,file='data',form='UNFORMATTED',access='DIRECT',recl=recl) write_stdlib(50,rec=rec) x,y,z ``` which, by default, would be just wrappers for the usual open and write statements. However, you could specify additional options like ```auto open_stdlib(50,file='data',form='UNFORMATTED',access='DIRECT',recl=recl, & volatile=.true.) ``` which would then store the data to RAM only. If required, the same data could be written once to the non-volatile file system at the end of the calculation (this is usually what we do). On a cluster, one could pass the MPI communicator ```auto open_stdlib(50,file='data',form='UNFORMATTED',access='DIRECT',recl=recl, & volatile=.true.,MPI_Comm=mpi_comm_world) ``` which would allow data to be read by all nodes. This would require some nifty coding using asynchronous MPI communication. From our HPC point of view, this would be a great feature. [Next page](https://fortran-lang.discourse.group/t/gsoc-25-stdlib-filesystem/9798.md?page=2)