Comment 11 for bug 911507

Revision history for this message
Tyler Hicks (tyhicks) wrote :

On 2012-04-16 06:44:17, Mikko Rantalainen wrote:
> The point I was trying to make is that is not acceptable to paint over
> the problem of invalid files popping up in the lower file system. Yes,
> it causes a big usability problem but the real cause for the issue
> should be identified instead of hiding the issue.

Fair point. However, there are scenarios when the real cause is not
fixable.

For example, there is a small window of time in ecryptfs_create(),
between the lower inode being created and eCryptfs metadata being
generated and written out to the lower file. A loss of power between
those two events will likely result in a zero length lower file.

> Please, at least spam the syslog for each file you automatically "fix"
> so possible data loss is not done silently.

I don't see how data loss is possible when fixing up zero length files.
The lower file is empty, after all.

Whatever lead to the zero length lower file could theoretically be a
source of data loss, but that would be a bug that would be fixed.

I also don't think end users care to know that an empty file was fixed.
There is no action for them to take and the error message will only fill
up the logs and possibly confuse them. A debug level message may be
appropriate, though.

> Reporting the fixes is a bit problematic, though, because you don't
> want to leak the unencrypted filename to the log and the targeted end
> user cannot deal with anything more cryptic, I'm afraid.

If needed, this can be handled by printing the inode number.

>
> Would it be possible to have encrypted "lost+found" directory which
> contained original copy of every "fixed" file?

I don't see the point since they would all be empty files.