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. 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
