On Tue, Mar 15, 2011 at 16:49, Julian Foad <julianfoad_at_btopenworld.com> wrote:
> Ivan Zhakov wrote:
>> 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.
>
> For ... what?
for me :)
>> It should be big problem to generate random
>> name using current time and then try rename file to this name. Repeat
>> on error.
>
> I assume you mean "it should not be a big problem...".
>
Yes, I meant "should not be a big problem". Sorry.
--
Ivan Zhakov
Received on 2011-03-15 14:58:43 CET