On Sun, 4 Aug 2002, Randall R Schulz wrote:
> Has anyone else been branded an "Email abuser" by
> zamansky@..., zamansky@... and / or
> zamansky@...?
>
> It seems a single repeated message is an overly sensitive criteria for such
> a condemnation...
Relax, it's probably just some filtering software. I hope zamansky
realizes, as I once did, that mail filters which send replies are
intractable, an that two copies are not unusual from a mailing
list.
You never know where the auto reply will go, since the return address
can be forged. Imagine if everyone had such a filter, and then a whole
lot of spammers decided they were going to forge messages from a single
mailbox. That destination would be subject to an effective DDoS from
all the auto-reply filters.
That's not the only problem. Auto replying can create mail routing
loops. You can be clever with X-Loop headers, but what if something
in the loop munges them?
A while ago I wrote a cookie-based e-mail authentication system (in
Lisp, of course) that could be installed as a filter under procmail.
The algorithm worked, but it created too many problems. There
are just too many kinds of things you can receive that must be
exempt from such processing---such as, for instance, complaints and
threats from sysadmins of networks you've never heard of about turning
off your goddamned mail authentication sript or we will blackhole
your network block. :)
--
Meta-CVS: solid version control tool with directory structure versioning.
http://users.footprints.net/~kaz/mcvs.htmlhttp://freshmeat.net/projects/mcvs

Hi,
Sorry again.
The "Email abuse" message I referred to was not sent to the list, just to
me, but my mail filters mistakenly put it in my CLISP mailing list mailbox.
I should have realized that fact owing to the absence of the "[clisp-list]"
tag in the "Subject:" header.
Has anyone else been branded an "Email abuser" by
zamansky@..., zamansky@... and / or
zamansky@...?
It seems a single repeated message is an overly sensitive criteria for such
a condemnation...
Randy

Karsten,
Interesting.
This is the precise problem that Sam Steingold reported to the Cygwin mail
list just a few days ago. The head Cygwin developer, Chris Faylor (at
Redhat) has already devised a fix but it's only available in a patch
release of the Cygwin "kernel" (cygwin1.dll).
The problem, in short, is making a hard link to a symbolic link. That hard
link to a symbolic link does not get the ".lnk" suffix it needs and so is
not interpreted as a symbolic link, even though that's what its contents
really are (since it's just a nother name for the symbolic link).
I can suggest a work-around that might make things manageable for you.
Wherever appears an "ln" (plain old hard-link "ln" invocations) whose
target (first argument) is a symbolic link, the newly created link name
should manually / explicitly supply a ".lnk" suffix.
Thus:
# "symLinkTarget" is a symbolic link to some other file
# "hardLinkToTarget" is the hard link to create
# that should alias the "symLinkTarget"
# No good:
% ln symLinkTarget hardLinkToSymlink
# Work-around:
% ln symnlinkTarget hardLinkToSymlink.lnk
Here's an example:
% echo "realFile" >realFile
% ln -s realFile realFile-sl
# No good:
% ln realFile-sl realFile-sl-hl1
# Work-around:
% ln realFile-sl realFile-sl-hl2.lnk
# Test
% cat realFile
realFile
% cat realFile-sl
realFile
% od -c realFile-sl-hl1
0000000 L \0 \0 \0 001 024 002 \0 \0 \0 \0 \0 300 \0 \0 \0
0000020 \0 \0 \0 F \f \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
0000040 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
0000060 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 001 \0 \0 \0
0000100 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \b \0 r e
0000120 a l F i l e \b \0 r e a l F i l e
0000140
% cat realFile-sl-hl2
realFile
You can also simplly rename, via "mv", the existing hardlinks to the
symbolic links that have no ".lnk" suffix:
% mv realFile-sl-hl1 realFile-sl-hl1.lnk
% cat realFile-sl-hl1.lnk
realFile
I hope that helps. I'll let you and Sam (and the CLISP list) know when a
release version of Cygwin is available that fixes this problem.
Lastly, so you know and can think about the consequences, the fix that
Chris Faylor has devised is simply to resolve the symbolic link when making
a hard link to it. Thus a request to make a hard link to the symbolic link
will end up making a hard link to the ultimate target of the symbolic link
instead.
Good luck. Feel free to ask more about this or other Cygwin issues.
Randall
At 04:09 2002-08-04, Karsten wrote:
>regarding the potential cygwin tar problems:
>
>Let me first describe the effects:
>Downloading and installing clisp-2.29-i686-unknown-cygwin_nt-5.0-1.3.12.tar.gz
>results in the following error:
>
>$ make
>gcc -O base/modules.o base/lisp.a base/libsigsegv.a base/libintl.a
>base/libicon
>v.a base/libreadline.a base/libavcall.a base/libcallback.a -lncurses -lm
>-o base
>/lisp.run
>base/libintl.a: file not recognized: File format not recognized
>collect2: ld returned 1 exit status
>make: *** [base/lisp.run] Error 1
>
>Inspecting libintl.a shows that it is a very short file containing some
>binary fields and fianlly some bytes looking like gettext/intl/libint.a
>gettext\intl\libintl.a
>
>Similar things happens with nearly all files in the distribution.
>Interesting enough is src: all .lisp files are broken, all fasl files are
>correct.
>
>Analysing this a bit further one can see that both fasl and lisp files are
>copied with the same instruction in the make distrib
>
>ln $(LISPFILES) $(FASFILES) $(TOPDIR)/src
>
>Ok, so a simple ln is not the problem.
>
>By further inspecting the origin of the lispfiles in the current
>directory one notes an important difference: The *.lisp files are already
>links ,e.g.
>lrwxrwxrwx 1 default 544 153 Aug 3 23:53 xcharin.lisp ->
>../src/x
>charin.lisp
>
>By further investigation in the makefile one finds that the *.lisp files
>in the directory are generated via
>ln -s, i.e. are symbolic links.
>
>Conclusion:
>In Cygwin applying ln -s to a file and afterwards ln to the link results
>in an unusable file. Since the same chain of instructions works fine in my
>Linux, I assume this is a problem within cygwin.
>
>Now it seems i shoudn't have said that tar is the culprit, the problems
>seems to be a step earlier.
>
>Karsten
>
>PS:
>A while ago somebody asked why bother with cygwin at all if there are so
>many problems with clisp. One reason is that at least on my box cygwin
>clisp is twice as fast a the windows clisp. It is even faster than in
>Linux, probably because I used gcc 304 in cygwin and gcc 2.95 something in
>Linux.
Randy

Karsten,
Interesting.
This is the precise problem that Sam Steingold reported to the Cygwin mail
list just a few days ago. The head Cygwin developer, Chris Faylor (at
Redhat) has already devised a fix but it's only available in a patch
release of the Cygwin "kernel" (cygwin1.dll).
The problem, in short, is making a hard link to a symbolic link. That hard
link to a symbolic link does not get the ".lnk" suffix it needs and so is
not interpreted as a symbolic link, even though that's what its contents
really are (since it's just a nother name for the symbolic link).
I can suggest a work-around that might make things manageable for you.
Wherever appears an "ln" (plain old hard-link "ln" invocations) whose
target (first argument) is a symbolic link, the newly created link name
should manually / explicitly supply a ".lnk" suffix.
Thus:
# "symLinkTarget" is a symbolic link to some other file
# "hardLinkToTarget" is the hard link to create
# that should alias the "symLinkTarget"
# No good:
% ln symLinkTarget hardLinkToSymlink
# Work-around:
% ln symnlinkTarget hardLinkToSymlink.lnk
Here's an example:
% echo "realFile" >realFile
% ln -s realFile realFile-sl
# No good:
% ln realFile-sl realFile-sl-hl1
# Work-around:
% ln realFile-sl realFile-sl-hl2.lnk
# Test
% cat realFile
realFile
% cat realFile-sl
realFile
% od -c realFile-sl-hl1
0000000 L \0 \0 \0 001 024 002 \0 \0 \0 \0 \0 300 \0 \0 \0
0000020 \0 \0 \0 F \f \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
0000040 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
0000060 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 001 \0 \0 \0
0000100 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \b \0 r e
0000120 a l F i l e \b \0 r e a l F i l e
0000140
% cat realFile-sl-hl2
realFile
You can also simplly rename, via "mv", the existing hardlinks to the
symbolic links that have no ".lnk" suffix:
% mv realFile-sl-hl1 realFile-sl-hl1.lnk
% cat realFile-sl-hl1.lnk
realFile
I hope that helps. I'll let you and Sam (and the CLISP list) know when a
release version of Cygwin is available that fixes this problem.
Lastly, so you know and can think about the consequences, the fix that
Chris Faylor has devised is simply to resolve the symbolic link when making
a hard link to it. Thus a request to make a hard link to the symbolic link
will end up making a hard link to the ultimate target of the symbolic link
instead.
Good luck. Feel free to ask more about this or other Cygwin issues.
Randall
At 04:09 2002-08-04, Karsten wrote:
>regarding the potential cygwin tar problems:
>
>Let me first describe the effects:
>Downloading and installing clisp-2.29-i686-unknown-cygwin_nt-5.0-1.3.12.tar.gz
>results in the following error:
>
>$ make
>gcc -O base/modules.o base/lisp.a base/libsigsegv.a base/libintl.a
>base/libicon
>v.a base/libreadline.a base/libavcall.a base/libcallback.a -lncurses -lm
>-o base
>/lisp.run
>base/libintl.a: file not recognized: File format not recognized
>collect2: ld returned 1 exit status
>make: *** [base/lisp.run] Error 1
>
>Inspecting libintl.a shows that it is a very short file containing some
>binary fields and fianlly some bytes looking like gettext/intl/libint.a
>gettext\intl\libintl.a
>
>Similar things happens with nearly all files in the distribution.
>Interesting enough is src: all .lisp files are broken, all fasl files are
>correct.
>
>Analysing this a bit further one can see that both fasl and lisp files are
>copied with the same instruction in the make distrib
>
>ln $(LISPFILES) $(FASFILES) $(TOPDIR)/src
>
>Ok, so a simple ln is not the problem.
>
>By further inspecting the origin of the lispfiles in the current
>directory one notes an important difference: The *.lisp files are already
>links ,e.g.
>lrwxrwxrwx 1 default 544 153 Aug 3 23:53 xcharin.lisp ->
>../src/x
>charin.lisp
>
>By further investigation in the makefile one finds that the *.lisp files
>in the directory are generated via
>ln -s, i.e. are symbolic links.
>
>Conclusion:
>In Cygwin applying ln -s to a file and afterwards ln to the link results
>in an unusable file. Since the same chain of instructions works fine in my
>Linux, I assume this is a problem within cygwin.
>
>Now it seems i shoudn't have said that tar is the culprit, the problems
>seems to be a step earlier.
>
>Karsten
>
>PS:
>A while ago somebody asked why bother with cygwin at all if there are so
>many problems with clisp. One reason is that at least on my box cygwin
>clisp is twice as fast a the windows clisp. It is even faster than in
>Linux, probably because I used gcc 304 in cygwin and gcc 2.95 something in
>Linux.

regarding the potential cygwin tar problems:
Let me first describe the effects:
Downloading and installing clisp-2.29-i686-unknown-cygwin_nt-5.0-1.3.12.tar.gz
results in the following error:
$ make
gcc -O base/modules.o base/lisp.a base/libsigsegv.a base/libintl.a
base/libicon
v.a base/libreadline.a base/libavcall.a base/libcallback.a -lncurses -lm -o
base
/lisp.run
base/libintl.a: file not recognized: File format not recognized
collect2: ld returned 1 exit status
make: *** [base/lisp.run] Error 1
Inspecting libintl.a shows that it is a very short file containing some
binary fields and fianlly some bytes looking like gettext/intl/libint.a
gettext\intl\libintl.a
Similar things happens with nearly all files in the distribution.
Interesting enough is src: all .lisp files are broken, all fasl files are
correct.
Analysing this a bit further one can see that both fasl and lisp files are
copied with the same instruction in the make distrib
ln $(LISPFILES) $(FASFILES) $(TOPDIR)/src
Ok, so a simple ln is not the problem.
By further inspecting the origin of the lispfiles in the current directory
one notes an important difference: The *.lisp files are already links ,e.g.
lrwxrwxrwx 1 default 544 153 Aug 3 23:53 xcharin.lisp ->
../src/x
charin.lisp
By further investigation in the makefile one finds that the *.lisp files in
the directory are generated via
ln -s, i.e. are symbolic links.
Conclusion:
In Cygwin applying ln -s to a file and afterwards ln to the link results in
an unusable file. Since the same chain of instructions works fine in my
Linux, I assume this is a problem within cygwin.
Now it seems i shoudn't have said that tar is the culprit, the problems
seems to be a step earlier.
Karsten
PS:
A while ago somebody asked why bother with cygwin at all if there are so
many problems with clisp. One reason is that at least on my box cygwin
clisp is twice as fast a the windows clisp. It is even faster than in
Linux, probably because I used gcc 304 in cygwin and gcc 2.95 something in
Linux.

Community

Help

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

I agree to receive quotes, newsletters and other information from sourceforge.net and its partners regarding IT services and products. I understand that I can withdraw my consent at any time. Please refer to our Privacy Policy or Contact Us for more details