This is the mail archive of the cygwin-apps mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: setup-2.ini problems/anomalies


On Fri, Aug 15, 2008 at 05:26:53PM +0200, Corinna Vinschen wrote:
>On Aug 15 11:20, Christopher Faylor wrote:
>> On Fri, Aug 15, 2008 at 04:05:40PM +0200, Corinna Vinschen wrote:
>> >On Aug 15 15:59, Dr. Volker Zell wrote:
>> >> >>>>> Corinna Vinschen writes:
>> >> 
>> >>     > That's probably a result of using only the latest package in the
>> >>     > release-2 area when creating the union fs.  They should be fixed by
>> >>     > either making all the test versions curr, or by copying the curr
>> >>     > versions over from release to release-2.  Can you do that at one
>> >>     > point, Volker?  I need some time for debugging now.
>> >> 
>> >> Done for emacs*, xemacs* and grace packages.
>> >
>> >Cool, thanks.
>> 
>> For the record, this is not the way to fix this particular problem
>> either.  I've removed all of the recently-created duplicate copies.
>
>Your response would be much more helpful if you would tell us how to fix
>these problems instead of just telling that this one way is not the way
>to fix the problem.

Q: What's the point of the unionfs?

A: To avoid the requirement of making duplicate copies of the entire
release area while still allowing customization.

So, explictly duplicating files goes against the whole idea of a
unionfs.

Given that, when a file is not showing up in the release-2 area that
exists in the release area you can either report the problem here and
let me fix it, which I am happy to do (especially when there are
problems with my own packages) or you can investigate how the unionfs
works which is what I just did, knowing that making copies was not
right.

The script that I use to unmount and remount this (and I'm not suggesting
that anyone should run this - please don't) is ~cgf/bin/union-remount.
That script shows you the command line used to mount release-2 is:

unionfs -o cow -o allow_other -o use_ino -o uid=22790 \
	-o gid=65521 \
/sourceware/snapshot-tmp/cygwin-release-2=rw:/sourceware/ftp/anonftp/pub/cygwin/release=ro \
/export/u0/sourceware/sourceware/ftp/anonftp/pub/cygwin/release-2

Reading the unionfs man page, you'd see that
/sourceware/snapshot-tmp/cygwin-release-2 is the "top branch".  Since
there are only two directories and one is marked "ro" it would make
sense that the meta data associated with the unionfs would be stored
there.

So, I cd'ed to sourceware/snapshot-tmp/cygwin-release-2 and typed "ls
-a", saw that there was a ".unionfs" directory there and cd'ed to that
location.  It contains a directory structure similar to ~release-2 but
the directories contain files like "xemacs-21.4.19-3.tar.bz2_HIDDEN~".
Since the file release-2/xemacs/xemacs-21.4.19-3.tar.bz2 does not exist,
it makes sense that this file must be what is used to flag the unionfs
file system.  Removing it causes the file to spring into existence in
release-2.

With the exception of the fact that I knew about union-remount command
and vaguely remembered that fuse-unionfs stored files with a _HIDDEN~
extension, all of the above is what I figured out in the last hour.  I
don't expect that anyone else would know how to do this.  I'm just
asking that we don't start polluting the release-2 area with duplicate
copies of files.  That is just a future "doubt" about unionfs waiting to
happen - "I deleted file X but it is still showing up in ~release-2.
unionfs sucks."

So the short answer is if this happens again, just notify me and I'll
fix it.  I would have fixed this when I read the cygwin-apps email but
all of this happened before I got on the computer this morning.

cgf


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]