Bert Huijben wrote:
> > -----Original Message-----
> > From: Julian Foad [mailto:julian.foad_at_wandisco.com]
> >
> > I'm not clear exactly what problem we would avoid by eliminating the
> > "select a unique name" step of this process. Is it what I describe
> > below at the end of note [1] - that a scanner might be more likely to
> > re-scan the content, and therefore more likely to cause a delay?
>
> No, the problem I try to avoid is
> * you create a file
> <virus scanner opens the file to verify that it is not a virus>
> * you delete the file (after the virusscanner releases the file)
> * you rename a file to be at the old location
>
> While we really need something like
> * rename to a unique name.
> <virusscanner ignores the file, because it was already scanned at the original location>
>From discussing on IRC we agree that the main concern is that this
involves too many separate filesystem operations, rather than any
specific problem with a particular step.
I have committed it as is in r1075942, and would like to improve it as a
follow-up.
Options for improvement:
(a) Don't open a pristine file with FILE_SHARE_DELETE. Instead,
accept that an attempt to delete it may fail, and if that happens, leave
the there as an orphan. When adding a pristine file, if it already
exists on disk then just keep the copy that already exists. When
cleaning up orphan files, if a delete fails, just leave the file there.
Consider implementing automatic clean-up to prevent orphan files from
accumulating indefinitely.
(b) Find or write a "rename to a unique name" function that operates
in a single step instead of a creating a new file and then overwriting
it.
(c) Don't rename the file before deleting it; instead, just delete it.
On Windows, when adding a new file, if a file with that name already
exists, *then* rename the existing file before moving the new file into
place. (We can't just keep the existing file because it is pending
deletion and will disappear when the reader finishes reading it.)
Pros and cons:
(a) This would reduce the number of file system operations to a
minimum. It would involve bypassing APR to avoid the FILE_SHARE_DELETE
flag, which is not ideal but possible.
(b) This would remove one of the file system operations. It would
involve writing a function similar to APR's fall-back implementation of
apr_file_mktemp() that exists for systems that do not provide a
"mkstemp" system API. I'm not sure if there are any concrete problems
with doing this sort of thing in "user space".
(c) This would remove two of the file system operations. It sounds
straightforward.
Comments?
- Julian
Received on 2011-03-01 19:14:08 CET