Re: [Help-tar] Extraction performance problem

[Jakob Bohm]

On 06/02/2015 17:39, Paul Eggert wrote:
> Jakob Bohm wrote:
> > It is not as much a direct requirement as an indirect one.
> >
> > Specifically, for local filesystems, there is no other way in
> > which a user mode application (such as a DB engine) can control
> > when its data has reached stable storage after closing the file
> > handle.
>
> There is no indirect requirement either.  User mode applications that
> care about stable data are supposed to use fdatasync or fsync or
> something like that. 'close' is not required to ensure that the data
> have hit stable storage, and on most operating systems I believe 'close'
> does not do that.  This is for obvious performance reasons.  The
> GNU/Linux man page for 'close', for example, says "A successful close
> does not guarantee that the data has been successfully saved to disk, as
> the kernel defers writes."
>
> If some virus scanners have trouble in this area, that's something that
> needs to be fixed in the virus scanners; it shouldn't require changing
> all other applications to work around the virus scanners' performance
> deficiencies.

I am afraid this is an observation of the general behavior of this class
of programs.  The primary reason for this behavior is that the kernels
they run on top of restrict the options for where in the VFS processing
chain they can be called to do their work.

I have actually tried one virus scanner that forks off its actual
scanning of freshly created files so it doesn't hold back close() calls.
The result: Failed software builds as the linker's attempt to open
recently created .o files conflict with the virus scanner still checking
the newly created code for Thompson attacks (it's a millisecond level
race condition and doesn't happen on each run, but it shows the dangers
of trying not to slow down close()).

Another reason is that it would be a severe security vulnerability if
someone could upload a piece of malware to a boot-executed location,
then crash the machine to prevent the virus scanner from seeing the
bad code before it is run during the next boot (before the virus
scanner itself is loaded).

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded