As muru says, you shouldn't have to back up steam.pipe. Steam should be able to re-create it if it is missing. However, when backing up your ~/.steam folder, you should check if you also have a ~/.local/share/Steam folder. If so, you'll probably want to back it up too. It usually contains most of the files associated with a Steam installation, including your installed Steam games.
I have written the rest of this answer in case:
- You want to know why you had trouble copying it with Nautilus and
cp.
- You want to know how to copy files like
steam.pipe, in case you do ever need to do so.
The executive summary is that you should use rsync for your backups. See below for details, explanation, and alterantives.
Why steam.pipe Is Special
steam.pipe is a FIFO, a.k.a. a named pipe:
ek@Io:~/.steam$ ls -l steam.pipe
prw------- 1 ek ek 0 Mar 7 20:12 steam.pipe
ek@Io:~/.steam$ file steam.pipe
steam.pipe: fifo (named pipe)
FIFOs are not a regular files, but instead are special filesystem entries that one may interact with as though they are files. Writing to the FIFO stores data in memory, where it remains until the FIFO is read from. Reading from a FIFO obtains data in the order they were written (so it is First In, First Out).
Why You Had Trouble Copying It
There are actually two distinct behaviors that one might want, when attempting to copy a FIFO. Which one you want depends on the situation.
- You might want to duplicate the FIFO, i.e., make another FIFO. (In this context, that's what you want.)
- You might want to read data from the FIFO, i.e., copy its contents. (This might not seem like "copying," but remember, this is analogous to what happens when you copy a file--the file is opened, its data are read, and the same data are written to a new file.)
You tried two programs:
- Nautilus automatically detects special entries such as FIFOs, refuses to copy from them, and warns you that it has done so.
cp reads data from the FIFO, rather than making a copy of the FIFO itself. If there are no data in the FIFO, cp stalls until some process writes to it.
Making Copies of Special Files (like FIFOs)
To duplicate a FIFO, you can use rsync with the --specials flag:
ek@Io:~$ cd steam-backup
ek@Io:~/steam-backup$ rsync --specials ~/.steam/steam.pipe .
ek@Io:~/steam-backup$ ls -l steam.pipe
prw------- 1 ek ek 0 Apr 22 11:43 steam.pipe
That's if you want to copy it separately. To copy a whole folder for archival purposes--that is, where you want most things to be the way they were before, so it works properly when restored--you can use rsync -a:
rsync -a .steam/ steam-backup
For more information about rsync, see "rsync" in the Ubuntu help wiki, the upstream rsync website, and man rsync (which explains specifically what the -a flag does).
cp is well suited for simple use cases, but I suggest rsync for making backups.
Specials Can Be Archived, Too
Another way to back up a folder is to make an archive of it with tar, and that will also automatically preserve FIFOs (i.e., they will be recreated on extraction):
ek@Io:~$ tar cvJf steam-backup.tar .steam
.steam/
.steam/registry.vdf
.steam/sdk32
.steam/bin64
.steam/root
.steam/steam_install_agreement.txt
.steam/steam
.steam/steam.pipe
.steam/steam.pid
.steam/bin
.steam/sdk64
.steam/bin32
Re-making the FIFO Manually
If you were missing a FIFO (either in a backup, or in general) and need to restore it, you can just create a new one with mkfifo.
You'll want to create it with the correct permissions. Running ls -l on steam.pipe shows a permissions mask of prw-------. p just means it's a named pipe (FIFO). The rest means it's readable and writable by its owner and has no other permissions (see FilePermissions for details). The octal permissions mask is thus 600 (or 0600), so you'll want to pass -m 600 to mkfifo:
ek@Io:~/steam-backup$ mkfifo -m 600 steam.pipe
ek@Io:~/steam-backup$ ls -l steam.pipe
prw------- 1 ek ek 0 Apr 22 12:09 steam.pipe
Duplicating a FIFO Doesn't Duplicate Its "Contents"
This is not a problem for backups, but you should know that duplicating a FIFO (for example, with rsync) just makes a new FIFO like it. If there are data in the FIFO ready to be read, the data will not be available in the new FIFO.
The reason this is not a problem for backups is that FIFOs are not for long-term storage. They're not really even for storage at all. Data in a FIFO are not written to disk, and when a process writes to a FIFO, the write is not even reported to the process as successful until the data have been read. (Similarly, if a process reads from a FIFO with no data in it, the read will stall until data are written.)
You can see this in action, and also get a better sense of how FIFOs work, by making one of your own and experimenting with it. You can create a new FIFO foo with default permissions with mkfifo foo, and redirect text to it with a command like echo 'Hello, world!' > foo. This will stall, as nothing has read the text yet. Then, in another terminal (e.g., another Terminal tab) read the text with cat foo and see what happens in each terminal.
