I am trying to delete a file and while it works fine through the shell, when I call my script from another program, instead of deleting the file, it merely changes the permissions to something odd:

$ touch example.txt
$ ls -la example.txt
-rw-r--r--  1 user users 0 Mar 24 21:49 example.txt
$ rm example.txt
$ ls -la example.txt
-r-S--S---  1 user users 0 Mar 24 21:49 example.txt

I have tried running both the rm command as well as the mv command, and if I mv the file onto a different file system (which works by copying the file then deleting the source) I get the same result. The permissions are not always the same - here are some examples of what I have seen:


What could cause the rm command to refuse to delete the file and instead only change the permissions, but to change the permissions randomly each time?

If I run the rm command from a fresh shell then it works fine, but I want to run it from within an application which launches shell scripts with exec().

Clearly the problem has something to do with the execution environment if it works in a normal shell but fails inside the exec() shell, however I don't even know where to start looking. Everything is running as the same user in the same folder.

Can anyone offer any tips about how to cause this behaviour to happen, or where to start looking to figure out what's going on?

1 Answer 1


Ok just realised what was happening. It turns out that the program was running the exec() task in the background, and an earlier command was still running and operating on the file when the mv or rm in question was run.

So what was happening was this:

  1. First program opened the file and started reading it.
  2. The problematic mv or rm command ran, removing the file as normal.
  3. First program recreated the file and wrote its changes out.

Because the program was designed to overwrite the file it was working on, it didn't supply any permissions when it went to open the file for writing, expecting the existing permissions to be reused. But as the file had been deleted in the middle of this process, a new file was created with whatever random number happened to be in memory for the unused parameter specifying the file permissions.

Changing the process so that the second command didn't run until the first one had finished fixed the problem.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .