Patch pushed to stable as 24fd94ed1cc0, resolving. dov, thanks for being
persistent on this.

ping

(patch still applies cleanly against latest crew 44c5157474e7)

new version of the patch, with caching. 

opener already caches this information; and on the other hand, util has no
state; so opener has to pass the cached information to util.set_flags as a new
argument.

I added the new argument to all calls of set_flags, but they should probably be
checked by someone who understands the context better...

On Sun, 2008-06-08 at 16:09 +0000, Dov Feldstern wrote:
> Dov Feldstern <dfeldstern@fastimap.com> added the comment:
> 
> Attached find a patch as Matt suggested.
> 
> I also fixed set_flags itself, although in our current situation this will have
> no effect, since by the time set_flags sees the symlink it will already be a
> link. However, I think that set_flags should do the right thing, without relying
> on it's caller. Alternatively, the entire handling of symlinks in set_flags
> could perhaps be removed?

This is looking better. But I'd really like us to only call the
filesystem check functions once per hg invocation, caching their results
in localrepo.

Well, I wanted to do this; however, it is necessary to have a non-symlink fs in
order to test this. I'm working with a vfat image mounted through the loopback
device, but I don't know how to do this in a test. Any ideas?

dov, could you perhaps write a test for the current erratic behavior and add it
to your patch? That way, it may be easier to prevent this from happening again.

Attached find a patch as Matt suggested.

I also fixed set_flags itself, although in our current situation this will have
no effect, since by the time set_flags sees the symlink it will already be a
link. However, I think that set_flags should do the right thing, without relying
on it's caller. Alternatively, the entire handling of symlinks in set_flags
could perhaps be removed?

@pmezard: I can confirm that it works on Windows; however, it does *not* work on
linux on a non-symlinking fs mount...

@mpm: I'll look in the direction you're suggesting...

Reverting the patch is a step in the wrong direction. The current code deletes
existing files, which simplifies various permission issues.

The -problem- is down in util.set_flags. For a symlink, we write out a -file-,
then read it back in and convert it to a symlink. Instead, we should just create
a symlink in the first place if that's allowed. Something like:

  if self._uselinks and "l" in flags:
     os.symlink(data, f)
  else:
     file("f", "w").write(data)

BTW, I have pywin32 installed

I cannot reproduce it on Windows as of 37eedb1a1848, built from sources.

I tried to add a clone test to tests/test-no-symlinks, and create a simple repo
with a symlink under MacOSX and clone it under Windows, with or without --pull.

Can you confirm the issue still exists ?

that would be great, thanks!

I might have a look at this.

The attached patch appears to fix the issue, and doesn't break any existing
tests. I basically just undid the offending changeset, with a minor update
(set_exec no longer exists).

Cloning a repo containing symlinks to a non-symlink-capable filesystem aborts
with message:
abort: Operation not permitted

bisect finds the following:

The first bad revision is:
changeset:   5703:14789f30ac11
user:        Matt Mackall <mpm@selenic.com>
date:        Thu Dec 27 22:27:47 2007 -0600
summary:     wwrite: simplify with util.set_flags