2020-10-30 14:08:56 -04:00
---
stage: none
group: unassigned
2020-11-26 01:09:20 -05:00
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
2020-10-30 14:08:56 -04:00
---
2015-10-26 08:42:09 -04:00
# Shared files
Historically, GitLab has been storing shared files in many different
directories: `public/uploads` , `builds` , `tmp/repositories` , `tmp/rebase` (EE),
etc. Having so many shared directories makes it difficult to deploy GitLab on
shared storage (e.g. NFS). Working towards GitLab 9.0 we are consolidating
these different directories under the `shared` directory.
2020-12-16 10:10:18 -05:00
This means that if GitLab begins storing puppies in some future version
2015-10-26 09:28:31 -04:00
then we should put them in `shared/puppies` . Temporary puppy files should be
stored in `shared/tmp` .
2015-10-26 08:42:09 -04:00
In the GitLab application code you can get the full path to the `shared`
directory with `Gitlab.config.shared.path` .
## What is not a 'shared file'
Files that belong to only one process, or on only one server, should not go in
`shared` . Examples include PID files and sockets.
## Temporary files and shared storage
Sometimes you create a temporary file on disk with the intention of it becoming
'official'. For example you might be first streaming an upload from a user to
disk in a temporary file so you can perform some checks on it. When the checks
pass, you make the file official. In scenarios like this please follow these
rules:
- Store the temporary file under `shared/tmp` , i.e. on the same filesystem you
want the official file to be on.
- Use move/rename operations when operating on the file instead of copy
operations where possible, because renaming a file is much faster than
copying it.
