On Sat, 13 Aug 2011, Guillem Jover wrote:
None of the other file types really need the deferred renames, and I
actually rather not have deferred renames at all! but oh well. Also
because we need to have the immediate rename code path in any case for
the directories I don't see the point in
Guillem Jover wrote:
This is misleading on Linux, but it's not a safe portable assumption
to make on POSIX in general as that behaviour is not specified and as
such is implementation specific
Ok, here's a patch with better behavior. On Linux and similar platforms,
it just opens the file for
Jonathan Nieder wrote:
To fix that, we should fsync() each file with multiple hard links only
once and then rename all links, so the logic to skip fsync would be no
longer needed.
... and here's a patch on top implementing that.
---
debian/changelog | 13 ++---
src/archives.c |
tag 635683 + patch
thanks
Hi,
On Fri, 12 Aug 2011, Jonathan Nieder wrote:
Ok, here's a patch with better behavior. On Linux and similar platforms,
it just opens the file for reading. If fsync fails with errno == EBADF,
it falls back to opening for writing, and if that fails with errno ==
Processing commands for cont...@bugs.debian.org:
tag 635683 + patch
Bug #635683 [dpkg] dpkg --unpack: »/usr/bin/perl5.12.4.dpkg-new« cannot be
opened: The program cannot be executed or altered/changed (busy)
Added tag(s) patch.
thanks
Stopping processing here.
Please contact me if you need
Hi,
Raphael Hertzog wrote:
Instead of making yet another exception for hardlinks, it's time
to decide that deferred rename is the norm and only directories
should be exempted from this.
Makes perfect sense. Thanks!
Here's the remainder of the train of thought I sent before. I
On Fri, 2011-08-12 at 22:09:55 +0200, Raphael Hertzog wrote:
On Fri, 12 Aug 2011, Jonathan Nieder wrote:
--- a/src/archives.c
+++ b/src/archives.c
@@ -851,7 +851,8 @@ tarobject(void *ctx, struct tar_entry *ti)
* in .dpkg-new.
*/
- if (ti-type == tar_filetype_file ||
7 matches
Mail list logo
