Directories with incorrect permissions

[dag-erling]

In production, we have seen directories on the destination side with mode 0600 instead of 0750. We assume that this is the result of the copier being interrupted (because the master process was terminated and killed all its tasks) after creating the directory but before setting the correct mode. Suggested improvements:

1. In the copier, either in copyfile_open() or in the code that calls it, add the user executable bit to the mode bitmask we pass to mkdir() if and only if the file in question is a directory.
2. In tsdfx_copy_wrap() in the main program, create a copy task for directories if the ownership or permissions don't match; currently, we only create a copy task if the target does not exist or the directory is due for deletion.

[dag-erling]

I wrote a test script which suggests that my analysis is incorrect, or at least incomplete. It occurred to me that there is a race condition between the creation of a directory and the creation / copying of the files it contains, since the tasks may be paralellized, but that does not explain the butchered directory permissions (I have even seen a few with u=r,g=s).

[petterreinholdtsen]

I suspect this issue can fill up the syslog disk, if there are lots of files that should go into a directory with such incorrect permissions.

[petterreinholdtsen]

I've tracked down this issue. The problem is tsdfx_copier() calling copyfile_open() with permission set to 0600 also for directories. I'm preparing a patch. Without the fix, the test-simplecopy.sh check fail 30-90% of the time, while with the fix in place, it succeeds every time.

[petterreinholdtsen]

Fixed with pull request #102 .