# Image Source File-System

**URL:** https://discourse.paraview.org/t/image-source-file-system/6448
**Category:** ParaView Support
**Created:** [February 11, 2021, 6:27pm UTC](https://discourse.paraview.org/t/image-source-file-system/6448 "2021-02-11T18:27:39Z")
**Posts on this page:** 1
**Page:** 1

<div class="post-metadata">

### Author: ![theodorebaltis](https://discourse.paraview.org/letter_avatar_proxy/v4/letter/t/e480ec/32.png) [@theodorebaltis](https://discourse.paraview.org/u/theodorebaltis)
#### Post date: [February 11, 2021, 6:27pm UTC](https://discourse.paraview.org/t/image-source-file-system/6448/1 "2021-02-11T18:27:39Z")

</div>

Starting a new topic to focus discussion a the point made in another topic by @mconti :

> [@PVSM ParaView State - Saving-Loading-Productivity](https://discourse.paraview.org/t/pvsm-paraview-state-saving-loading-productivity/5190/9):
>
> Having the ability to load everything from server side while in C/S mode would be a GREATLY appreciated feature. Besides what has been touched on previously, currently images and other data is treated differently than reader data, which doesn’t make sense to me and makes scripting harder than it needs to be. For example, working in C/S with a windows client and linux server. All data is stored server side. I create a state file that loads simulation data and then I add in some background image…

Regardless of the file-system to which state files are saved, I strongly agree that when in client/server mode all data (specifically talking about but not limited to things like images here - background, logo, path traced environment, etc.) used in the session should come from the same file-system, so the server.

Currently at least those three mentioned sources (logo, background, path traced environment) need be loaded from the client-side machine, so one ends up with a state file that has paths unique to their local machine and thus **makes the state file completely unshareable**.

I acknowledge that there is a valid counter-argument. That one may not have the images needed on the server, and the typical user may have some trouble pushing them to the server (though I would argue that by saying learning scp is simple enough).

However, I believe that implementing the solution proposed by @mconti and I to solve this issue of surrendering state files useless on any other machine easily outweighs the merits of that counter-argument.

I also acknowledge that another possible solution is to provide the user the option as to which file-system to use for these sources, as has been discussed to address a separate issue in another thread:  
[https://discourse.paraview.org/t/proposed-general-rule-for-save-and-load-supported-files-on-remote-and-or-local-filesystems/5398](https://discourse.paraview.org/t/proposed-general-rule-for-save-and-load-supported-files-on-remote-and-or-local-filesystems/5398)  
But that’s probably unnecessarily complex. I think it’s reasonable to just say that in client/server mode all input comes from the server. As to where all output goes is another story… 🙂