RE: Subversion problems with svn switch, svn co, svn switch, because of 'wrong' permissions in .svn/ directories
[EMAIL PROTECTED] wrote: Spiro Trikaliotis wrote on 26 April 2008 10:42: Anyway, this reminds me of another problem: Personally, I install Cygwin with DOS line endings (CR/LF). That's the reason why I have built CVS.EXE myself some moons ago ;), as the pre-built version did not like this setup. (IIRC, the outputs were garbled in many places. At the time when I tested it, it was a known issue on the info-cvs mailing list.) At least CVS checks out the text files in the native format of the platform - as I am using Cygwin with CR/LF, this is the CR/LF format. Unfortunately, with SVN from Cygwin, this is not true anymore. For the Cygwin version of SVN, the native format for text files uses Unix line endings (LF) only. As there a way to get it fixed? Or is it again something for upstream? A config item to override the default setting for native eol-style might well be a useful feature enhancement patch for upstream; it would be useful on all platforms, not just Cygwin. Well, Cygwin's Subversion simply does not respect text mounts (compared to CVS) and that's hardly something for upstream. - Jörg -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Subversion problems with svn switch, svn co, svn switch, because of 'wrong' permissions in .svn/ directories
Jörg Schaible wrote on 29 April 2008 07:39: [EMAIL PROTECTED] wrote: Say, has your Outlook Quotefix gone screwy too? Spiro Trikaliotis wrote on 26 April 2008 10:42: Unfortunately, with SVN from Cygwin, this is not true anymore. For the Cygwin version of SVN, the native format for text files uses Unix line endings (LF) only. As there a way to get it fixed? Or is it again something for upstream? A config item to override the default setting for native eol-style might well be a useful feature enhancement patch for upstream; it would be useful on all platforms, not just Cygwin. Well, Cygwin's Subversion simply does not respect text mounts (compared to CVS) and that's hardly something for upstream. Hmm, well it might or might not be, it depends what method it's using to determine the native mode. If it was simply fopen()ing a file in text mode and writing, it would of course respect textmode mounts automatically. Perhaps it manages it all manually by always writing in binary mode, and it inherently assumes that all filing systems operate in the same textmode, and some test it does misleads it? It also depends on the attitude of the upstream maintainers to accepting platform-specific patches. cheers, DaveK -- Can't think of a witty .sigline today -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Subversion problems with svn switch, svn co, svn switch, because of 'wrong' permissions in .svn/ directories
Dave Korn wrote: Jörg Schaible wrote on 29 April 2008 07:39: [EMAIL PROTECTED] wrote: Say, has your Outlook Quotefix gone screwy too? Spiro Trikaliotis wrote on 26 April 2008 10:42: Unfortunately, with SVN from Cygwin, this is not true anymore. For the Cygwin version of SVN, the native format for text files uses Unix line endings (LF) only. As there a way to get it fixed? Or is it again something for upstream? A config item to override the default setting for native eol-style might well be a useful feature enhancement patch for upstream; it would be useful on all platforms, not just Cygwin. Well, Cygwin's Subversion simply does not respect text mounts (compared to CVS) and that's hardly something for upstream. Hmm, well it might or might not be, it depends what method it's using to determine the native mode. If it was simply fopen()ing a file in text mode and writing, it would of course respect textmode mounts automatically. Perhaps it manages it all manually by always writing in binary mode, and it inherently assumes that all filing systems operate in the same textmode, and some test it does misleads it? It also depends on the attitude of the upstream maintainers to accepting platform-specific patches. Well, it might be very well that Subversion always uses binary mode for file I/O, it will even convert text files on its own if the svn:eol-style property is set (unless your file has no mixed EOLs). OTOH it cannot know that an environment uses two different native modes, that's quite a Cygwin speciality. So, it's some kind of catch-22 ;-) - Jörg -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Subversion problems with svn switch, svn co, svn switch, because of 'wrong' permissions in .svn/ directories
Hello, * On Tue, Apr 29, 2008 at 12:58:53PM +0200 Jörg Schaible wrote: Well, it might be very well that Subversion always uses binary mode for file I/O, Indeed, it seems so. This topic came up before (see the thread started at http://svn.haxx.se/dev/archive-2005-02/0993.shtml), and the way Subversion works has not been changed yet. In http://svn.haxx.se/dev/archive-2005-02/1034.shtml, it is described as follows: Look at the function svn_subst_eol_style_from_value() in the file subversion/libsvn_subr/subst.c. That function determines what the various svn:eol-style settings mean and you will see that native leads to APR_EOL_STR, i.e. Subversion gets the value from APR. There is even a work-around available to change this behaviour: You could change svn_subst_eol_style_from_value() and rebuild Subversion, or you could change APR_EOL_STR and rebuild all of APR, APR-UTIL and Subversion, it depends what behaviour you want. Anyway, I already asked for the Antivirus-Workaround upstream, I will propose some change here, too. Unfortunately, as Subversion is currently at 1.5 RC4, I doubt they will include such changes for 1.5. Anyway, I will try. Best regards, Spiro. -- Spiro R. Trikaliotis http://opencbm.sf.net/ http://www.trikaliotis.net/ http://www.viceteam.org/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Subversion problems with svn switch, svn co, svn switch, because of 'wrong' permissions in .svn/ directories
Spiro Trikaliotis wrote on 26 April 2008 10:42: Anyway, this reminds me of another problem: Personally, I install Cygwin with DOS line endings (CR/LF). That's the reason why I have built CVS.EXE myself some moons ago ;), as the pre-built version did not like this setup. (IIRC, the outputs were garbled in many places. At the time when I tested it, it was a known issue on the info-cvs mailing list.) At least CVS checks out the text files in the native format of the platform - as I am using Cygwin with CR/LF, this is the CR/LF format. Unfortunately, with SVN from Cygwin, this is not true anymore. For the Cygwin version of SVN, the native format for text files uses Unix line endings (LF) only. As there a way to get it fixed? Or is it again something for upstream? A config item to override the default setting for native eol-style might well be a useful feature enhancement patch for upstream; it would be useful on all platforms, not just Cygwin. cheers, DaveK -- Can't think of a witty .sigline today -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Subversion problems with svn switch, svn co, svn switch, because of 'wrong' permissions in .svn/ directories
Hello Dave, I am sorry for the late answer, but first, I was on a business trip, and secondly, I was speaking with the AntiVirus support team to try to find a fix or, at least, work-around for this issue. * On Mon, Apr 21, 2008 at 11:35:51AM +0100 Dave Korn wrote: Spiro Trikaliotis wrote on 21 April 2008 11:24: Hello, * On Sat, Apr 19, 2008 at 06:59:56PM +0200 I wrote: Ok, here is the description: Sometimes (!) when I do a svn co or svn up, I get the following error: svn: Can't move 'src/arch/riscos/.svn/tmp/all-wcprops' to 'src/arch/riscos/.svn/all-wcprops': Permission denied [...] It is a problem of my Anti-Virus solution. So, I have already contacted the company which develops it. Would you mind telling us the name of the AV software at fault, so that we can add it to the list? In my case, it is Antivir Professional (Version 8) by Avira, a German company (formerly know as H+BEDV). The running process is avgnt.exe, a registry key path is HKLM\SOFTWARE\Avira\Antivir Workstation\Path which contains a path to the installed Antivir (in my case, C:\Programme\Avira\Antivir Workstation\ - yes, I am using a German Windows XP, thus, \Programme\) Note, however, that this problem did not occur with the former version 7. It seems to be a new feature of the new version 8 which came out on April 14th. I am still working with the support to find a solution to this. They have come up with two work-arounds for the problem: 1. Put SVN.EXE (and CVS.EXE, btw.) into the list of files that are not scanned. With this, I do not have any problems anymore. Anyway, I consider this to be a big security problem. or 2. Put the directory where the files are to be checked out into an exception list which is not scanned. Again, this work-around works. I consider this to be a big security problem too. Why don't I like these solutions? I regularly check out sources from different open internet servers (for example, SourceForge). I would like to get the program checking them out as well as the checked-out sandboxes under control of the AV program. There was a third work-around proposal: 3. In Antivir, there is a list of file extensions which are to be checked for malware. By default, this list contains the most important file extensions (like .exe, .bat, .cmd, .com, and-so-on). If I disable this list and tell Antivir to check files on ALL extensions, the problem does not completely vanish, but it happens much less than before! Unfortunately, no. 3 has another draw-back: At least for my artificial test .cmd script I wrote to demonstrate the problem to the Avira support, the problem has moved. The script repeatedly performs the following steps: a. (generate a file test.tmp) b. copy test.tmp to test.2.tmp c. move test.2.tmp over test.tmp d. repeat steps b. and c. Without the work-around #3, the above test does not fail at all. Only the second variant fails: m. (generate a file test) n. copy test to test.2 o. move test.2 over test p. repeat steps n. and o. Here, step o. fails. You see the difference? In o., the file is named test (w/o extension), in c., it is named test.tmp (w/ extension). If I use the work-around #3, o. does not fail anymore, but c. does. So, the problem is moved. Interestingly, though, it does not fail as often in c. as it did with the original settings, failing in o. BTW: On my machine, the test m., n., o., p. fails approx. 0.2% of the tries. Of course, looking at the script I wrote and the results, it is clear why SVN and CVS fail mostly on larger check-outs: First, they use this scheme rather often (for example, CVS generates CVS/Entries.tmp and moves it over CVS/Entries), but it does not occur that frequently this it will break always. I am still trying to convince the AV vendor to accept this as a bug and fix this issue. IMHO, the scheme generate a new temporary file and move it over the original one is used very often in programs, thus, this issue might affect many programs. Perhaps, programs like Word for Windows do not fail on this scheme either because this problem does not happen that frequently, or because their files all have file extensions. I will report here if I find a suitable solution. Regards, Spiro. -- Spiro R. Trikaliotis http://opencbm.sf.net/ http://www.trikaliotis.net/ http://www.viceteam.org/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Subversion problems with svn switch, svn co, svn switch, because of 'wrong' permissions in .svn/ directories
Hello Bernard, * On Thu, Apr 24, 2008 at 01:08:16AM +0800 Bernard Blackham wrote: On Mon, Apr 21, 2008 at 11:35:51AM +0100, Dave Korn wrote: Ah, this problem happens sometimes: the anti-virus on-access scanner keeps a handle open to the file a bit too long, interfering with normal operations that require unshared access. I gather that this issue has been brought up several times over the last few years already but nothing has been done about it other than to say disable your virus checker/indexing service. Oh... Had this issue been brought up for SVN, or in general? Before I posted, I had checked on this mailing list (and others), but I could not find it being reported before. Why doesn't the Cygwin SVN build simply just #define WIN32 (or whatever it takes) so the code which is _already in SVN_ to work around this problem is actually used to fix the issue? I have not seen anyone give a reason as to why this shouldn't be done. (If there is, please feel free to flame me :) As we have seen from other responses, there are some reasons why this is not done. Anyway, this reminds me of another problem: Personally, I install Cygwin with DOS line endings (CR/LF). That's the reason why I have built CVS.EXE myself some moons ago ;), as the pre-built version did not like this setup. (IIRC, the outputs were garbled in many places. At the time when I tested it, it was a known issue on the info-cvs mailing list.) At least CVS checks out the text files in the native format of the platform - as I am using Cygwin with CR/LF, this is the CR/LF format. Unfortunately, with SVN from Cygwin, this is not true anymore. For the Cygwin version of SVN, the native format for text files uses Unix line endings (LF) only. As there a way to get it fixed? Or is it again something for upstream? Best regards, Spiro. -- Spiro R. Trikaliotis http://opencbm.sf.net/ http://www.trikaliotis.net/ http://www.viceteam.org/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Subversion problems with svn switch, svn co, svn switch, because of 'wrong' permissions in .svn/ directories
On Mon, Apr 21, 2008 at 11:35:51AM +0100, Dave Korn wrote:
* On Sat, Apr 19, 2008 at 06:59:56PM +0200 I wrote:
Ok, here is the description: Sometimes (!) when I do a svn co or svn
up, I get the following error:
svn: Can't move 'src/arch/riscos/.svn/tmp/all-wcprops' to
'src/arch/riscos/.svn/all-wcprops': Permission denied
It is a problem of my Anti-Virus solution. So, I have already contacted
the company which develops it.
Ah, this problem happens sometimes: the anti-virus on-access scanner keeps a
handle open to the file a bit too long, interfering with normal operations
that require unshared access.
I gather that this issue has been brought up several times over the
last few years already but nothing has been done about it other than
to say disable your virus checker/indexing service.
Why doesn't the Cygwin SVN build simply just #define WIN32 (or
whatever it takes) so the code which is _already in SVN_ to work
around this problem is actually used to fix the issue? I have not
seen anyone give a reason as to why this shouldn't be done. (If
there is, please feel free to flame me :)
I work with a repository of about 2GB and nearly a hundred thousand
files. I have never been able to check this out with Cygwin SVN
without it failing - company policy does not allow disabling of
virus checkers (as does the lack of admin rights). The only reliable
workaround I have found is to:
(a) check it out with WinSVN (the Win32 build of SVN) - this
always works flawlessly, but creates non-Cygwin symlinks;
(b) go through and remove the symlinks in Cygwin:
svn status | awk '/^~/ {print $2}' | xargs rm -f
(c) svn update in Cygwin to restore the small handful of symlinks
in Cygwin-style symlinks
taking about twice as long. It would be much easier if the SVN
binary in Cygwin would DTRT in the first place.
Is there a showstopping reason why this can't be done? I would be
more than happy to test it out :)
Cheers,
Bernard.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: Subversion problems with svn switch, svn co, svn switch, because of 'wrong' permissions in .svn/ directories
Bernard Blackham wrote: Why doesn't the Cygwin SVN build simply just #define WIN32 (or whatever it takes) so the code which is _already in SVN_ to work around this problem is actually used to fix the issue? I have not seen anyone give a reason as to why this shouldn't be done. (If there is, please feel free to flame me :) Because defining WIN32 would enable all of the native Windows codepaths and disable all the POSIX codepaths... that would not work very well considering that all Cygwin functions expect POSIX paths not Win32 paths. You'd essentially be building a native Win32 svn client that has no POSIX capability but still uses the Cygwin library, the worst of all possible worlds. But I'm quite sure you wouldn't even get that far since all those MSVCRT-specific things would stop it from even building, such as 1-arg vs 2-arg mkdir(), %lld vs %I64d, : vs ;, _foo vs foo, etc. What really needs to happen is to find just those places where a virus scanner workaround exists and change #ifdef _WIN32 to #if defined(_WIN32) || defined(__CYGWIN__). Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Subversion problems with svn switch, svn co, svn switch, because of 'wrong' permissions in .svn/ directories
Bernard Blackham wrote on 23 April 2008 18:08: Why doesn't the Cygwin SVN build simply just #define WIN32 (or whatever it takes) so the code which is _already in SVN_ to work around this problem is actually used to fix the issue? I have not seen anyone give a reason as to why this shouldn't be done. (If there is, please feel free to flame me :) I don't know in this specific case, but in the general case: nobody else is reporting having this problem apart from you. There are millions of other programs out there that aren't cygwin, and it seems Just Plain Wrong to twist and contort cygwin until it's bent completely out of shape trying to fix other people's bug in other people's software. (Historically, that's one of the prime reasons why the windows OS itself is such a godawful mess) Simply defining WIN32, btw, will not work. It will bring in all sorts of code that assumes MSVCRT functions are available, and just break the .. (oh, hang on, I see Brian has just addressed this point, so I'll leave off there). I work with a repository of about 2GB and nearly a hundred thousand files. I have never been able to check this out with Cygwin SVN without it failing - company policy does not allow disabling of virus checkers (as does the lack of admin rights). Again; if it is your company policy to force you to use buggy AV software that breaks the vital tools you need to perform your work, then your company's policy is bad and wrong, and nobody is particuarly inclined to try and work around it in cygwin, potentially impairing the operation of cygwin for the everybody-else-in-the-world who does /not/ work for your company. It would be much easier if the SVN binary in Cygwin would DTRT in the first place. It DOES do absolutely the right thing, and is prevented from success by external force majeure. All cygwin does is open, read, write, and close files. Any system on which those fundamental operations can fail owing to the interference of another application is fundamentally broken, and it is not cygwin's fault for in any way not doing the right thing. Is there a showstopping reason why this can't be done? I would be more than happy to test it out :) Of course there is no reason why it is impossible in theory, but there may be engineering reasons such as performance impact why it is not desirable in practice. SVN is an open source project like any other, so if you want this changed, your best bet is to send a patch upstream to the responsible maintainers. It would greatly strengthen the argument for inclusion of the patch if you accompanied it with timings of testruns that show it does not cause any significant performance degradation - not, of course, when compared with the version that can't fully run under your buggy antivirus, but when compared with the unpatched version running under no antivirus, or when comparing the two as run under a different antivirus; you can't justify causing a slowdown for everybody by pointing to your one broken machine and saying it's not slower on that, for example. cheers, DaveK -- Can't think of a witty .sigline today -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Subversion problems with svn switch, svn co, svn switch, because of 'wrong' permissions in .svn/ directories
Spiro Trikaliotis wrote on 21 April 2008 11:24: Hello, * On Sat, Apr 19, 2008 at 06:59:56PM +0200 I wrote: Ok, here is the description: Sometimes (!) when I do a svn co or svn up, I get the following error: svn: Can't move 'src/arch/riscos/.svn/tmp/all-wcprops' to 'src/arch/riscos/.svn/all-wcprops': Permission denied Here, I have lied obviously. The problem is not related to the Subversion client of Cygwin: In fact, it has nothing to do with Cygwin at all. It is a problem of my Anti-Virus solution. So, I have already contacted the company which develops it. Ah, this problem happens sometimes: the anti-virus on-access scanner keeps a handle open to the file a bit too long, interfering with normal operations that require unshared access. I am sorry for the confusion, and I hope no one of you invested much time to debug this problem yet. No problem at all, in fact thanks for the report: we keep a list of programs that are (or have been in some versions) known to cause interference of this sort with cygwin: http://cygwin.com/faq/faq-nochunks.html#faq.using.bloda Would you mind telling us the name of the AV software at fault, so that we can add it to the list? It would also be helpful if you could identify a running process, installed executable or registry key path that can be used to detect if the AV in question is installed, as we can then add automatic detection in cygcheck.exe; hopefully, if anyone else runs up against this problem, we can save them the pain of trying to diagnose it. http://opencbm.sf.net/ http://www.trikaliotis.net/ http://www.viceteam.org/ Yay cool retro! cheers, DaveK -- Can't think of a witty .sigline today -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Subversion problems with svn switch, svn co, svn switch, because of 'wrong' permissions in .svn/ directories
Hello, * On Sat, Apr 19, 2008 at 06:59:56PM +0200 I wrote: I have run into the following issue with Subversion on cygwin. Note that this problem does not occur when running the original Subversion versions from subversion.tigris.org; unfortunately, the ones from trigris.org do not work in a cygwin bash. Ok, here is the description: Sometimes (!) when I do a svn co or svn up, I get the following error: svn: Can't move 'src/arch/riscos/.svn/tmp/all-wcprops' to 'src/arch/riscos/.svn/all-wcprops': Permission denied Here, I have lied obviously. The problem is not related to the Subversion client of Cygwin: In fact, it has nothing to do with Cygwin at all. It is a problem of my Anti-Virus solution. So, I have already contacted the company which develops it. I am sorry for the confusion, and I hope no one of you invested much time to debug this problem yet. Regards, Spiro. -- Spiro R. Trikaliotis http://opencbm.sf.net/ http://www.trikaliotis.net/ http://www.viceteam.org/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Subversion problems with svn switch, svn co, svn switch, because of 'wrong' permissions in .svn/ directories
Hello,
I have run into the following issue with Subversion on cygwin. Note that
this problem does not occur when running the original Subversion
versions from subversion.tigris.org; unfortunately, the ones from
trigris.org do not work in a cygwin bash.
Ok, here is the description: Sometimes (!) when I do a svn co or svn up,
I get the following error:
svn: Can't move 'src/arch/riscos/.svn/tmp/all-wcprops' to
'src/arch/riscos/.svn/all-wcprops': Permission denied
Note that the directory ('src/arch/riscos/') can be different.
Additionally, sometimes, it is not all-wcprops, but the file
entries.
To me, this seems to be related to the permissions of these files: 444
aka r--r--r--. It seems to fail to overwrite the file in
.svn/all-wcprops with the working copy from .svn/tmp/all-wcprops, as the
permissions are not set for writing.
As this error does not occur always, I would expect there is a race
between different code paths.
Note that a svn switch always results in the above error line. Thus,
for debugging purposes, using svn switch might be a much better
alternative.
This problems happens on two different computers, both running XP SP2. I
attached the output of cygcheck -s -v -r cygcheck.out to this mail,
as requested on http://cygwin.com/problems.html.
Oh... If it is important, I have used DOS line endings when I installed
Cygwin. Additionally, today, I upgraded to the latest version, just to
make sure it is not fixed yet. Additionally, I could not find this
problem mentioned in this mailing list here.
Regards
Spiro.
--
Spiro R. Trikaliotis http://opencbm.sf.net/
http://www.trikaliotis.net/ http://www.viceteam.org/
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: Subversion problems with svn switch, svn co, svn switch, because of 'wrong' permissions in .svn/ directories
Hello, * On Sat, Apr 19, 2008 at 06:59:56PM +0200 I wrote: This problems happens on two different computers, both running XP SP2. I attached the output of cygcheck -s -v -r cygcheck.out to this mail, it was the old where is the attachment? problem. I am sorry. Here, you can find it. Regards, Spiro. -- Spiro R. Trikaliotis http://opencbm.sf.net/ http://www.trikaliotis.net/ http://www.viceteam.org/ Cygwin Configuration Diagnostics Current System Time: Sat Apr 19 18:37:27 2008 Windows XP Professional Ver 5.1 Build 2600 Service Pack 2 Path: C:\cygwin\home\tri\bin C:\cygwin\usr\local\bin C:\cygwin\bin C:\cygwin\bin C:\cygwin\usr\X11R6\bin c:\WINDOWS\system32 c:\WINDOWS c:\WINDOWS\System32\Wbem c:\Programme\Microsoft Driver Test Manager\Controller\ c:\Programme\GNU\GnuPG\pub C:\cygwin\bin Output from C:\cygwin\bin\id.exe (nontsec) UID: 1005(tri) GID: 513(Kein) 513(Kein) 545(Benutzer) 555(Remotedesktopbenutzer) Output from C:\cygwin\bin\id.exe (ntsec) UID: 1005(tri) GID: 513(Kein) 513(Kein) 545(Benutzer) 555(Remotedesktopbenutzer) SysDir: C:\WINDOWS\system32 WinDir: C:\WINDOWS USER = 'tri' PWD = '/home/tri/cbm/vice.svn.greg' CYGWIN = 'ntsec tty' HOME = '/home/tri' MAKE_MODE = 'unix' HOMEPATH = '\cygwin\home\tri' MANPATH = '/usr/local/man:/usr/share/man:/usr/man::/usr/ssl/man:/usr/X11R6/man' HOSTNAME = 'agger' TERM = 'screen' SHELL = '/bin/bash' PROCESSOR_IDENTIFIER = 'x86 Family 6 Model 13 Stepping 8, GenuineIntel' WINDIR = 'C:\WINDOWS' SSH_CLIENT = '192.168.113.2 3857 22' TEXDOCVIEW_txt = 'cygstart %s' TEXDOCVIEW_dvi = 'cygstart %s' OLDPWD = '/home/tri/cbm' USERDOMAIN = 'NT-AUTORIT�T' SSH_TTY = '/dev/tty0' OS = 'Windows_NT' ALLUSERSPROFILE = 'C:\Dokumente und Einstellungen\All Users' TEMP = '/cygdrive/c/WINDOWS/TEMP' COMMONPROGRAMFILES = 'C:\Programme\Gemeinsame Dateien' SSH_AUTH_SOCK = '/tmp/ssh-2Bn7arNQDO/agent.3084' USERNAME = 'SYSTEM' TEXDOCVIEW_pdf = 'cygstart %s' PROCESSOR_LEVEL = '6' MAIL = '/var/spool/mail/tri' SYSTEMDRIVE = 'C:' TEXDOCVIEW_html = 'cygstart %s' USERPROFILE = 'C:\Dokumente und Einstellungen\tri' PS1 = '\[\e]0;[EMAIL PROTECTED] \[\e[33m\]\w\[\e[0m\]\n\$ ' PROCESSOR_ARCHITECTURE = 'x86' SHLVL = '1' PATHEXT = '.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH' HOMEDRIVE = 'C:' COMSPEC = 'C:\WINDOWS\system32\cmd.exe' LOGNAME = 'tri' TMP = '/cygdrive/c/WINDOWS/TEMP' SYSTEMROOT = 'C:\WINDOWS' PRINTER = 'OKIPAGE 14ex (von SIEG)' CVS_RSH = '/bin/ssh' PROCESSOR_REVISION = '0d08' SSH_CONNECTION = '192.168.113.2 3857 192.168.113.13 22' TEXDOCVIEW_ps = 'cygstart %s' INFOPATH = '/usr/local/info:/usr/share/info:/usr/info:' PROGRAMFILES = 'C:\Programme' NUMBER_OF_PROCESSORS = '1' COMPUTERNAME = 'AGGER' _ = '/usr/bin/cygcheck' HKEY_CURRENT_USER\Software\Cygnus Solutions HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2 HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\Program Options HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2 (default) = '/cygdrive' cygdrive flags = 0x0020 HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/ (default) = 'C:\cygwin' flags = 0x0008 HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/bin (default) = 'C:\cygwin/bin' flags = 0x0008 HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/lib (default) = 'C:\cygwin/lib' flags = 0x0008 HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\Program Options c: hd NTFS 70001Mb 88% CP CS UN PA FC d: cd N/AN/A C:\cygwin / system textmode C:\cygwin/bin /usr/bin system textmode C:\cygwin/lib /usr/lib system textmode . /cygdrive system textmode,cygdrive Found: C:\cygwin\bin\awk.exe Found: C:\cygwin\bin\bash.exe Found: C:\cygwin\bin\cat.exe Found: C:\cygwin\bin\cp.exe Found: C:\cygwin\bin\cpp.exe Not Found: crontab Found: C:\cygwin\bin\find.exe Found: C:\cygwin\bin\gcc.exe Found: C:\cygwin\bin\gdb.exe Found: C:\cygwin\bin\grep.exe Found: C:\cygwin\bin\kill.exe Found: C:\cygwin\bin\ld.exe Found: C:\cygwin\bin\ls.exe Found: C:\cygwin\bin\make.exe Found: C:\cygwin\bin\mv.exe Found: C:\cygwin\bin\patch.exe Found: C:\cygwin\bin\perl.exe Found: C:\cygwin\bin\rm.exe Found: C:\cygwin\bin\sed.exe Found: C:\cygwin\bin\ssh.exe Found: C:\cygwin\bin\sh.exe Found: C:\cygwin\bin\tar.exe Found: C:\cygwin\bin\test.exe Not Found: vi Found: C:\cygwin\bin\vim.exe 103k 2007/09/16 C:\cygwin\bin\cygapr-1-0.dll - os=4.0 img=1.0 sys=4.0 cygapr-1-0.dll v0.0 ts=2007/9/16 20:04 70k 2007/09/16 C:\cygwin\bin\cygaprutil-1-0.dll - os=4.0 img=1.0 sys=4.0 cygaprutil-1-0.dll v0.0 ts=2007/9/16 20:33
