Hello,

It seems that shred utilizes a pattern of renaming and then unlinking.
However, I don't see the use of a lock for this pattern and so there is a
race condition and the shred command can fail. This test case is timing
sensitive, and therefore doesn't happen every time. But it happens
frequently. I am trying to write robust code that depends on shred and I
find this issue is problematic.

Test case:
$ touch a b c && for file in a b c; do shred -u -n 1 $file & done && wait
[1] 28262
[2] 28263
[3] 28264
shred: c: failed to remove: No such file or directory
[1]   Done                    shred -u -n 1 "$file"
[2]-  Done                    shred -u -n 1 "$file"
[3]+  Exit 1                  shred -u -n 1 "$file"


Other information:
$ shred --version
shred (GNU coreutils) 8.21
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html
>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Colin Plumb.

$ cat /etc/os-release
NAME="Ubuntu"
VERSION="14.04.6 LTS, Trusty Tahr"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 14.04.6 LTS"
VERSION_ID="14.04"
HOME_URL="http://www.ubuntu.com/"
SUPPORT_URL="http://help.ubuntu.com/"
BUG_REPORT_URL="http://bugs.launchpad.net/ubuntu/"

$ bash --version
GNU bash, version 4.3.11(1)-release (x86_64-pc-linux-gnu)
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html
>

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.