On Tue, Mar 15, 2011 at 16:49, Julian Foad <julianf...@btopenworld.com> wrote: > Ivan Zhakov wrote: >> On Tue, Mar 1, 2011 at 21:13, Julian Foad <julian.f...@wandisco.com> wrote: >> > Bert Huijben wrote: >> >> > -----Original Message----- >> >> > From: Julian Foad [mailto:julian.f...@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
