Re: Misterious warning about file system boundaries [It's a bug, not a mystery.]

2 messages, 2 authors, 2016-06-15 · open the first message on its own page

Re: Misterious warning about file system boundaries [It's a bug, not a mystery.]

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:48:57

Jeff King [off-list ref] writes:
Since the early-warning suggestion is generating false positives, and I
don't think there is a portable and reliable way around it, dropping it
makes sense to me.
Makes sense.  Let's make it so (I won't have time to do that myself until
late this evening, though).

Thanks.

Re: Misterious warning about file system boundaries [It's a bug, not a mystery.]

From: Jeff King <hidden>
Date: 2016-06-15 22:48:57

On Thu, Jun 10, 2010 at 07:53:47AM -0700, Junio C Hamano wrote:
Jeff King [off-list ref] writes:
quoted
Since the early-warning suggestion is generating false positives, and I
don't think there is a portable and reliable way around it, dropping it
makes sense to me.
Makes sense.  Let's make it so (I won't have time to do that myself until
late this evening, though).

Thanks.
Here it is with a nice commit message (though since it is only in next,
I guess you can just merge the early part and both 52b98a and my revert
will be dropped). It's on top of ld/discovery-limit-to-fs, of course.

Note that it would be possible to do a warning in some instances. We
just can't trust the on-disk index ce_dev information, so if you
actually refreshed two cross-filesystem entries we could detect that.
That is such a minority case that I doubt it is worth caring about,
though.

-- >8 --
Subject: [PATCH] Revert "write-index: check and warn when worktree crosses a filesystem boundary"

This reverts commit 52b98a7d2f12b5d0dd076221d40f8fa93598e11a.

The goal of that commit was to warn users early when their
worktree crossed filesystem boundaries. It worked by
comparing the st_dev stat information in the index, and
warning when we had more than one device.

However, the stat information may come from multiple runs,
and the st_dev field is not necessarily stable. In
particular, st_dev will change on Linux across reboots.
Index entries from the previous reboot will appear to come
from a different device, triggering a false positive.

Since this message is really only an early warning for
people who will be bit by the new
GIT_DISCOVERY_ACROSS_FILESYSTEM behavior, and because they
will get an actual error later on (when we can't find their
cross-filesystem .git directory), we can just scrap the
early warning.

Signed-off-by: Jeff King <redacted>
---
 read-cache.c |   14 --------------
 1 files changed, 0 insertions(+), 14 deletions(-)
diff --git a/read-cache.c b/read-cache.c
index e381ea5..f1f789b 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -1550,8 +1550,6 @@ int write_index(struct index_state *istate, int newfd)
 	struct cache_entry **cache = istate->cache;
 	int entries = istate->cache_nr;
 	struct stat st;
-	int first_valid_ent = -1;
-	int more_than_one_dev;
 
 	for (i = removed = extended = 0; i < entries; i++) {
 		if (cache[i]->ce_flags & CE_REMOVE)
@@ -1574,7 +1572,6 @@ int write_index(struct index_state *istate, int newfd)
 	if (ce_write(&c, newfd, &hdr, sizeof(hdr)) < 0)
 		return -1;
 
-	more_than_one_dev = 0;
 	for (i = 0; i < entries; i++) {
 		struct cache_entry *ce = cache[i];
 		if (ce->ce_flags & CE_REMOVE)
@@ -1583,19 +1580,8 @@ int write_index(struct index_state *istate, int newfd)
 			ce_smudge_racily_clean_entry(ce);
 		if (ce_write_entry(&c, newfd, ce) < 0)
 			return -1;
-		if (ce_uptodate(ce)) {
-			if (first_valid_ent < 0)
-				first_valid_ent = i;
-			else if (ce->ce_dev != cache[first_valid_ent]->ce_dev)
-				more_than_one_dev = 1;
-		}
 	}
 
-	if (more_than_one_dev &&
-	    !git_env_bool("GIT_DISCOVERY_ACROSS_FILESYSTEM", 0))
-		warning("working tree spans across filesystems but "
-			"GIT_DISCOVERY_ACROSS_FILESYSTEM is not set.");
-
 	/* Write extension data here */
 	if (istate->cache_tree) {
 		struct strbuf sb = STRBUF_INIT;
-- 
1.7.1.516.gd5539.dirty
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help