Effect of 'cp /dev/zero a' when file a exists

Question

If a exists and I type

cp /dev/zero a

can I be sure the old contents of a will be overwritten, or will I simply get the equivalent of

rm a
cp /dev/zero a

---

PS. I am not suggesting that this is the correct way securely to delete a file; I am merely curious about the effect of a certain command.

Answer 1

I suspect that, when you open a file to write it from the start, all the existing blocks will be freed immediately (still containing their existing contents), and your cp will acquire new blocks to zero-fill.

Further, your file will be extended until it fills the whole partition: the original size will not be honoured.

The dd command has an option conv=notrunc, and you would be able to find the original size using stat, round that up to whole blocks, and use the count and bs options to size the zeros to the same blocks as the original.

Edit: Confirmed by test that a shell > redirect retains same inode number, but immediately reduces file size to zero blocks and releases them to available space.

strace on cp shows vanilla overwrite of the file via mmap area:

open("foo.tiny", O_RDONLY)              = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=8192, ...}) = 0
open("foo.copy", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
fstat(4, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
fadvise64(3, 0, 0, POSIX_FADV_SEQUENTIAL) = 0
mmap(NULL, 139264, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fc295d30000
read(3, "\0\0\0\0"..., 131072) = 8192
write(4, "\0\0\0\0"..., 8192) = 8192
read(3, "", 131072)                     = 0
close(4)                                = 0
close(3)                                = 0
munmap(0x7fc295d30000, 139264)          = 0
lseek(0, 0, SEEK_CUR)                   = -1 ESPIPE (Illegal seek)
close(0)                                = 0
close(1)                                = 0
close(2)                                = 0

Conclusion has to be that cp will discard your confidential data into the free list, and overwrite whatever blocks it gets allocated afterwards.

This script demonstrates that dd will zeroise part or all of the existing blocks in a file, without freeing blocks, and without changing the inode. You may need to capture the actual BLKSZ and file Size from a stat command, and to use bash arithmetic to round up the size to a whole number of blocks. Also shows that dd will extend a file, and will write sparse data.

This produces about 100 lines of output, so I won't post that. It is benign. The Zero function is the meat of it.

#! /bin/bash
FN='./Erase.data'
BLKSZ=4096
#.. Zeroise a specified range of blocks (zero-based).
Zero () {   #:: (from, to)
dd 2>&1 ibs="${BLKSZ}" obs="${BLKSZ}" \
    seek="${1}" count="$(( $2 - $1 + 1 ))" \ 
    conv=notrunc if="/dev/zero" of="${FN}"

}
#.. Create a file of 8 * 4096B blocks, each labelled in every character.
Make () {   #:: (void)
AWK='   

function Block (sz, id, Local, buf) {
    buf = sprintf ("%*s", sz, "");
    gsub (/./, id, buf);
    printf ("%s", buf);
}
{ for (f = 2; f <= NF; ++f) Block( $1, $(f)); }
'
    echo "${BLKSZ}" {A..H} | awk "${AWK}" > "${FN}" 
}
#.. Reveal the file.
Show () {
echo; ls -l &quot;${FN}&quot;; stat &quot;${FN}&quot;; od -A d -t a &quot;${FN}&quot;; sleep 2 

}
Script Body Starts Here.
#.. Make the file and prove its contents.
Make &gt; &quot;${FN}&quot; &amp;&amp; Show 
Zero 3 6 &amp;&amp; Show 
Zero 0 1 &amp;&amp; Show 
Zero 0 7 &amp;&amp; Show 
Zero 220 231 &amp;&amp; Show 

This is an approximation to a production version.

#! /bin/bash
Usage () { expand -t 4 <<'EOF'
Usage: ZeroAllBlocks [-h] [files ...]
    Warning: this command is as brutal as rm -f.
    -h: shows this message.

    Zeroises (binary zero) all blocks of all the files named.
    Sparse blocks will then consume real disk space.

EOF
}
#.. Zeroise a specified range of blocks (zero-based).
Zero () {   #:: (Fn, blksz, seek, count)
local Fn=&quot;${1}&quot; blksz=&quot;${2}&quot; seek=&quot;${3}&quot; count=&quot;${4}&quot;

dd status=none ibs=&quot;${blksz}&quot; obs=&quot;${blksz}&quot; \ 
    seek=&quot;${seek}&quot; count=&quot;${count}&quot; \
    conv=notrunc if=&quot;/dev/zero&quot; of=&quot;${Fn}&quot;

}
#.. Process a file.
File () {   #:: (filename)
local Fn=&quot;${1}&quot; szFile szBlock nBlock

[[ -f &quot;${Fn}&quot; ]] || { printf '%s: No such file\n' &quot;${Fn}&quot;; return; }
[[ -w &quot;${Fn}&quot; ]] || { printf '%s: Not writable\n' &quot;${Fn}&quot;; return; }
read -r szFile szBlock &lt;&lt;&lt;$( stat --printf='%s %o\n' &quot;${Fn}&quot; )
nBlock=&quot;$(( (szFile + szBlock - 1) / szBlock ))&quot;
Zero &quot;${Fn}&quot; &quot;${szBlock}&quot; 0 &quot;${nBlock}&quot;

}
Script Body Starts Here.
[[ &quot;${1}&quot; = &quot;-h&quot; ]] &amp;&amp; { Usage; exit 2; }

for Fn in &quot;${@}&quot;; do File &quot;${Fn}&quot;; done

Answer 2

Why do you want to copy /dev/zero to some file?

• Do you want to securely delete a? Then cp is the wrong tool. Look into shred if you're using a hard disk, and fstrim if you're using an SSD. (There are very likely other tools I'm not aware of, so googling "secure delete" would be good.)

• Do you understand that /dev/zero is infinite in size? It will return zeros indefinitely and so cp will never finish until the file system containing a fills up.

• But, that might not ever happen because cp, as part of its sparse file detection, will suppress writes of all-zero pages.

• Do you want to create a file of a given size that is full of zeros? cp is still the wrong tool. You'll need to use dd so you can specify how many bytes to copy from /dev/zero.

Overall, use cp for copying an ordinary file to another ordinary file, where all you are concerned about is that the copy is logically equivalent.

If you're working with device files, or you're trying to control how the blocks of the original file are disposed of, you'll want to use another program.

Answer 3

It depends on the filesystem and storage device used. Generally filesystems will overwrite when you tell them to, unless you are using a filesystem optimized for raw flash memory; those special filesystems might implement wear leveling at the FS level and so would write into a different location.

But if the storage device is a regular SATA or NVMe SSD, it might do wear leveling internally anyway, and the real physical storage blocks will be different from what even the raw block device will show. So the "overwrite" will end up going to a different physical location even though the filesystem thinks it is definitely overwriting a particular block #.

But getting past the SSD's wear leveling system and reading the raw storage meaningfully should be a non-trivial technical hurdle, requiring specialist knowledge and possibly special hardware tools. And the SSD will probably pre-emptively erase any "overwritten" blocks as soon as practical anyway, to have as much erased blocks available for writing as possible, as the erasing is generally the limiting factor of SSD performance.