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? > 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...". - Julian
