On Tue, Mar 1, 2011 at 21:13, Julian Foad <julian.foad_at_wandisco.com> wrote:
> 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?
>
(b) Is best option for. It should be big problem to generate random
name using current time and then try rename file to this name. Repeat
on error.
--
Ivan Zhakov
Received on 2011-03-15 13:17:43 CET