On Tue, 2009-08-11 at 16:35 +0100, jcup...@gmail.com wrote: > 2009/8/11 <jcup...@gmail.com>: > > 2009/8/11 Alexander Larsson <al...@redhat.com>: > >> Clearly we should do at least 3, which will fix this case (and other > >> similar tempfile cases). However, given the extremely bad performance > >> here we should maybe add the extra API in 2 allowing apps to avoid the > >> cost when needed? Its kinda ugly to expose that to users, but the > >> performance cost is pretty ugly too... > > > > I'm probably being stupid here, but how about putting the fsync in a > > timeout? Instead of calling fsync() directly, add a new thing called > > g_fsync_queue() which queues up an fsync 'soon'. > > Oh ahem, I guess I'm thinking of sync() rather than fsync(). Though in > this case one sync() at the end of the delete would certainly be > faster than thousands of fsync()s.
But more unsafe. The aim of frequent fsync() is to be sure not to lose data. I don't know how standardized the trash "protocol" is, but maybe one keyfile by deleted file is too much. Some kind of batching would be good. Xav _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list