PC-Pine 4.61: "Unable to lock open folder"
Benny Siegert
At the university, I use PC-Pine for e-mails. However, in one lab (Windows
NT4 / 2000), this setup does not work. I cannot open any folder, all I get
is the error message "Unable to lock open folder".
Upon searching the archives, I have discovered that the problem may be a
read-only global temp directory. And indeed, C:\WINNT\Temp is not writable
as a normal user.
However, it was not me who invented this brain-dead setup, I just want to
read my e-mails. And editing the registry is forbidden via system
policies. Is there any workaround for this problem? I could do without
global locking as my mailboxes are locally kept in my private directory on
the server.
--Benny.
Mark Crispin
> Upon searching the archives, I have discovered that the problem may be a
> read-only global temp directory. And indeed, C:\WINNT\Temp is not writable
> as a normal user.
See if you can convince the admins to allow writing to the world temp
directory. Unfortunately, too much depends upon it being global to use
the per-user temp directory.
Otherwise, you'll just have to avoid using local mailbox files and access
all your mail (and postponed mail) via IMAP.
-- Mark --
http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.
Eduardo Chappa
:) On Thu, 9 Dec 2004, Eduardo Chappa wrote:
:) > Even though I believe I completely understand the issue in this case,
:) > I think that adding a TEMP environment variable, for users in this
:) > situation, would help them a lot, and not force them to use other
:) > programs that do not have this type of restrictions.
:)
:) Other mail programs do not have shareable mailboxes that can be written
:) simultaneously by multiple processes.
That's exactly my point. If the user knows that this is impossible
(e.g. those folders are only locally accessed by him/her), I see
no point in forbidding him from doing useful work because some other
external inexistent process will want to write to his mailbox. That's my
point. That's why I think that if the user wanted to use another TEMP for
his own locks, it would be of great help for him.
:) > On the other hand, seeing if it's possible to install Cygwin Pine
:) > would be a way to try to get around this issue, since Cygwin Pine
:) > does not require a writable C:\winnt\Temp directory.
:)
:) Cygwin Pine most certainly does require a writeable /tmp directory in
:) Cygwin's space.
Yes, and this comes for free once you install cygwin. You do not need to
do a "system install", you can do a "user install" only, so /tmp is
writable for this purpose.
:) You also have to install Cygwin.
Any person that can download programs from the internet and has enough
space in the hard drive can install cygwin, you do not need to go through
your administrator to do this.
On the other hand, is there anyway that transforming his mailboxes to unix
format, say, could help?. Obviously the mailutil program for PC would not
help, but again there's one for cygwin that could do the trick, and that
could be a better solution for him in case he wants to continue using
PC-Pine.
--
Eduardo
Patches/Help: http://www.math.washington.edu/~chappa/pine/
XML/RSS feed: http://www.math.washington.edu/~chappa/pine/pine.xml
Eduardo Chappa
:) On Thu, 9 Dec 2004, Benny Siegert wrote:
:) > Upon searching the archives, I have discovered that the problem may
:) > be a read-only global temp directory. And indeed, C:\WINNT\Temp is
:) > not writable as a normal user.
:)
:) See if you can convince the admins to allow writing to the world temp
:) directory. Unfortunately, too much depends upon it being global to use
:) the per-user temp directory.
I understand why this is a good advice in general, but I have worked in
systems where the restrictions over what a user can do are so big, that
the number of things that a computer can do gets restricted to only being
able to execute Microsoft products or other products that were previously
installed by the administrator. This being so, it may mean that the only
option that you may be giving this person is to move to Outlook Express
Even though I believe I completely understand the issue in this case, I
think that adding a TEMP environment variable, for users in this
situation, would help them a lot, and not force them to use other
programs that do not have this type of restrictions.
On the other hand, seeing if it's possible to install Cygwin Pine would be
a way to try to get around this issue, since Cygwin Pine does not require
a writable C:\winnt\Temp directory.
--
Mark Crispin
> Even though I believe I completely understand the issue in this case, I
> think that adding a TEMP environment variable, for users in this
> situation, would help them a lot, and not force them to use other
> programs that do not have this type of restrictions.
Other mail programs do not have shareable mailboxes that can be written
simultaneously by multiple processes.
> On the other hand, seeing if it's possible to install Cygwin Pine would be
> a way to try to get around this issue, since Cygwin Pine does not require
> a writable C:\winnt\Temp directory.
Cygwin Pine most certainly does require a writeable /tmp directory in
Cygwin's space. You also have to install Cygwin.
Mark Crispin
> > Other mail programs do not have shareable mailboxes that can be written
> That's exactly my point. If the user knows that this is impossible
> (e.g. those folders are only locally accessed by him/her)
I just spent a fair amount of time helping a user clean up trashed mailbox
files that he "knew was impossible" that any shared access would happen.
> I see
> no point in forbidding him from doing useful work because some other
> external inexistent process will want to write to his mailbox.
I see no point in forbidding people from doing useful work because some
twit write-protected the designated systemwide temp directory either.
It's all fine and good to talk about "inexistent" (sic) processes, but
reality does not match the talk. Users are often very unaware of what,
precisely, is going on under the covers.
> That's my
> point. That's why I think that if the user wanted to use another TEMP for
> his own locks, it would be of great help for him.
The entire point of the locks is to be systemwide; *not* per user and
certainly not dependent upon environment variables.
> > You also have to install Cygwin.
> Any person that can download programs from the internet and has enough
> space in the hard drive can install cygwin, you do not need to go through
> your administrator to do this.
A site which does not allow writes to the system temp directory is
probably not going to tolerate users installing large packages like
Cygwin.
I really wish that you would not advocate Cygwin Pine as a substitute for
PC Pine. Large parts of the c-client library used by Pine DO NOT WORK in
Cygwin Pine. Cygwin is not a true UNIX, and I do not pretend to support
Cygwin. I only made the mbx driver work as a special favor to you. I do
not want innocent people to follow your advice, encounter problems, and
expect us to help them.
> On the other hand, is there anyway that transforming his mailboxes to unix
> format, say, could help?
No, it will not.
I can not think of a worse idea than using a Cygwin-compiled mailutil.
That's almost a certain recipe for file corruption.
Eduardo Chappa
:) On Thu, 9 Dec 2004, Eduardo Chappa wrote:
:) > > Other mail programs do not have shareable mailboxes that can be
:) > > written simultaneously by multiple processes.
:) > That's exactly my point. If the user knows that this is impossible
:) > (e.g. those folders are only locally accessed by him/her)
:)
:) I just spent a fair amount of time helping a user clean up trashed
:) mailbox files that he "knew was impossible" that any shared access
:) would happen.
Did this happen with a writable C:\winnt\temp?. If not, that's not a
counterexample for any thing, it's just a case of a user who did not know
any better.
Somehow I do not think that any process, except Pine, is going to write to
saved-messages, and so what's the problem with allowing him to access that
mailbox, and not depend on a global configuration that is not useful for
him.
:) > I see no point in forbidding him from doing useful work because some
:) > other external inexistent process will want to write to his mailbox.
:)
:) I see no point in forbidding people from doing useful work because some
:) twit write-protected the designated systemwide temp directory either.
You can call names anyone you want, but the fact stands. He can't do
useful work.
:) It's all fine and good to talk about "inexistent" (sic) processes, but
:) reality does not match the talk. Users are often very unaware of what,
:) precisely, is going on under the covers.
Reality may match the talk if you know what you are doing. That's my
point!
:) > That's my point. That's why I think that if the user wanted to use
:) > another TEMP for his own locks, it would be of great help for him.
:)
:) The entire point of the locks is to be systemwide; *not* per user and
:) certainly not dependent upon environment variables.
Yes, but c-client has its own locks that other applications are unaware
of, so this is not a big problem. Locking c-client against itself can be
done for all applications very easily.
:) > > You also have to install Cygwin.
:) > Any person that can download programs from the internet and has
:) > enough space in the hard drive can install cygwin, you do not need to
:) > go through your administrator to do this.
:)
:) A site which does not allow writes to the system temp directory is
:) probably not going to tolerate users installing large packages like
:) Cygwin.
I've done it. It can be done.
:) I really wish that you would not advocate Cygwin Pine as a substitute
:) for PC Pine. Large parts of the c-client library used by Pine DO NOT
:) WORK in Cygwin Pine. Cygwin is not a true UNIX, and I do not pretend
:) to support Cygwin. I only made the mbx driver work as a special favor
:) to you. I do not want innocent people to follow your advice, encounter
:) problems, and expect us to help them.
Cygwin Pine can be used to do useful work (I do it all the time). Nevr had
this problem.
:) > On the other hand, is there anyway that transforming his mailboxes to
:) > unix format, say, could help?
:)
:) No, it will not.
Too bad.
:) I can not think of a worse idea than using a Cygwin-compiled mailutil.
:) That's almost a certain recipe for file corruption.
That's a talk that does not match my reality. Maybe you can show how it
can be done.
Thorsten Glaser
> I really wish that you would not advocate Cygwin Pine as a substitute for PC
> Pine. Large parts of the c-client library used by Pine DO NOT WORK in Cygwin
> Pine. Cygwin is not a true UNIX, and I do not pretend to support Cygwin. I
Ack. GNU cygwin is evil. Did you try MS Services for Unix / Interix?
I pretty much like it, it's got /bin/ls not ls.exe aka "you're kidding?" and
my shell - http://wiki.mirbsd.de/MirbsdKsh - works as-is on it, even as
system shell replacing the /bin/sh delivered with it :)
//mirabile
Benny, spare your "windows® fanboy" comments ;)
Mark Crispin
> Ack. GNU cygwin is evil. Did you try MS Services for Unix / Interix?
> I pretty much like it, it's got /bin/ls not ls.exe aka "you're kidding?" and
> my shell - http://wiki.mirbsd.de/MirbsdKsh - works as-is on it, even as
> system shell replacing the /bin/sh delivered with it :)
Interesting, thanks for the note.
I wouldn't go so far as to call Cygwin "evil" as I would say that it's
important to have a sensible view of what it is (and is not). Cygwin is
certainly excellent as a short-term shim to enable a UNIX application to
run under Windows; but it should not be viewed as a replacement to porting
that application.
Several facilities in Cygwin are implemented via Windows calls which are
"close but not exact." For example, UNIX has advisory locking but Cygwin
assumes that most programs would work alright using Windows mandatory
locking. PC Pine understands the native Windows environment; UNIX Pine
compiled under Cygwin does not.
Personally, I prefer to work in native mode on whatever operating system.
If I want a UNIX environment, I install UNIX; if I want a Windows
environment, I install Windows. In an extreme circumstance, I'll use
VMware.
Eduardo Chappa
:) Several facilities in Cygwin are implemented via Windows calls which
:) are "close but not exact." For example, UNIX has advisory locking but
:) Cygwin assumes that most programs would work alright using Windows
:) mandatory locking. PC Pine understands the native Windows environment;
:) UNIX Pine compiled under Cygwin does not.
I agree with you in that Cygwin does not emulate linux perfectly. I think
we agree on most things here, I see Cygwin as a port, not as a flavor of
Linux, Unix or Windows, but as a different entity. It seems to me that the
fallacy in your argument is that "Cygwin is Linux" in a twisted way. That
cygwin tries to look like Linux, yes. That is it Linux, not. I would never
use this as an argument against Cygwin, I'd simply say "Cygwin is neither
of both, so a different port (meaning code) is needed to deal with this
port". That's what a port is, after all (e.g. look at all the ports header
files and so on) it would be naive to pretend that there is one code for
all systems. Cygwin just needs a different code. I don't see the problem
with that. You seem to see it. We just disagree.
Still you have not shown how using the mailutil program that can be
downloaded with the setup.exe program one could corrupt a folder (either
in PC-Pine or Cygwin Pine). I'd like to see such proof.
Mark Crispin
> Still you have not shown how using the mailutil program that can be
> downloaded with the setup.exe program one could corrupt a folder (either
> in PC-Pine or Cygwin Pine). I'd like to see such proof.
I didn't say that.
I said that mailutil built for Cygwin can corrupt mailboxes.
Eduardo Chappa
:) On Fri, 10 Dec 2004, Eduardo Chappa wrote:
:) > Still you have not shown how using the mailutil program that can be
:) > downloaded with the setup.exe program one could corrupt a folder
:) > (either in PC-Pine or Cygwin Pine). I'd like to see such proof.
:)
:) I didn't say that.
:)
:) I said that mailutil built for Cygwin can corrupt mailboxes.
So, if I send you a test mailbox, could you tell me which command I would
have to run on it so that it gets corrupted by Cygwin mailutil?. I am very
interested in understanding how (meaning under which conditions) Cygwin
mailutil will corrupt a mailbox.
Mark Crispin
> So, if I send you a test mailbox, could you tell me which command I would
> have to run on it so that it gets corrupted by Cygwin mailutil?. I am very
> interested in understanding how (meaning under which conditions) Cygwin
> mailutil will corrupt a mailbox.
No mailbox format except for mbx works in Cygwin. Some will seem to work,
but there are known issues in which data corruption can happen. Many (but
not all) of these issues are in newline handling.
There is no point to running a Cygwin-build mailutil when there is a
perfectly good native Windows mailutil that is tested, supported, and
works.
Eduardo Chappa
:) On Fri, 10 Dec 2004, Eduardo Chappa wrote:
:) > So, if I send you a test mailbox, could you tell me which command I
:) > would have to run on it so that it gets corrupted by Cygwin
:) > mailutil?. I am very interested in understanding how (meaning under
:) > which conditions) Cygwin mailutil will corrupt a mailbox.
:)
:) No mailbox format except for mbx works in Cygwin.
Err, I use unix format, it works great. Why do claim it does not work? I'd
like to see specific evidence that this is so.
:) Some will seem to work, but there are known issues in which data
:) corruption can happen. Many (but not all) of these issues are in
:) newline handling.
So how do they happen? Can you send me a mailbox that I can run mailutil
on and corrupt it?. I want to see clear evidence of the issue. All you are
providing are very unclear arguments on when a corruption may happen, but
do not specify how the mailbox must look like, or which command is being
run on it, etc. I'd love to see specific details, that would be great.
:) There is no point to running a Cygwin-build mailutil when there is a
:) perfectly good native Windows mailutil that is tested, supported, and
:) works.
Maybe for you. Maybe for many others. Not everyone buy the same brands of
cars. Some are better than others. In this case, I do not see why
PC-Mailutil is better than Cygwin Mailutil, but it would be great to
understand why.
andreas mrs d.t ch
> On Thu, 9 Dec 2004, Benny Siegert wrote:
>> Upon searching the archives, I have discovered that the problem may be a
>> read-only global temp directory. And indeed, C:\WINNT\Temp is not writable
>> as a normal user.
>
> See if you can convince the admins to allow writing to the world temp
> directory. Unfortunately, too much depends upon it being global to use
> the per-user temp directory.
(sorry to reply to this message, but the original is not available
anymore)
I'm not a the author of Windows, but as a user and developer of Windows
software, I'd say an Windows installation with a not writable temp
directory is broken.
What is the temp directory used for? Save temporary data. Who saves this
data? The software started by the user.
The question is, whether c:\winnt\temp is the correct directory or if
there is another (might be a not existing) directory where the temp
environment variable points to (might be c:\temp).
Just my 2¢
Andreas
Benny Siegert
> On Thu, 9 Dec 2004, Eduardo Chappa wrote:
> > I see
> > no point in forbidding him from doing useful work because some other
> > external inexistent process will want to write to his mailbox.
>
> I see no point in forbidding people from doing useful work because some twit
> write-protected the designated systemwide temp directory either.
I just want to read my e-mail. I am fairly certain the administrator(s)
would not change the permissions in the temp directory just for me. The
answer would be "Use Eudora for mail, like all the others." But I just
switched from Eudora to PC-Pine because it was so awful.
> > That's my
> > point. That's why I think that if the user wanted to use another TEMP for
> > his own locks, it would be of great help for him.
>
> The entire point of the locks is to be systemwide; *not* per user and
> certainly not dependent upon environment variables.
You know, if I install pine in my home directory at X:\pine with folders
at X:\pine\mail, and I am the only one using pine from there, how should
there be any problem with locks? I certainly do not have any other
programs that write to the folders.
> A site which does not allow writes to the system temp directory is probably
> not going to tolerate users installing large packages like Cygwin.
Exactly.
--Benny.
andreas mrs d.t ch
> On Thu, 9 Dec 2004, Mark Crispin wrote:
>
>> On Thu, 9 Dec 2004, Eduardo Chappa wrote:
>> > I see
>> > no point in forbidding him from doing useful work because some other
>> > external inexistent process will want to write to his mailbox.
>>
>> I see no point in forbidding people from doing useful work because some twit
>> write-protected the designated systemwide temp directory either.
>
> I just want to read my e-mail. I am fairly certain the administrator(s)
> would not change the permissions in the temp directory just for me. The
> answer would be "Use Eudora for mail, like all the others." But I just
> switched from Eudora to PC-Pine because it was so awful.
If I understand correctly, you are not able to write to the temp
directory? (So that means, your system is broken?)
What about writing some small batch file to start pine? It would look as
follows:
@echo off
set TEMP=c:\blah
set TMP=c:\blah
pine
Of course, you have to use a directory where you can write to.
(of course, only if you are allowed to write a batch file and if you
have any directory with write access, nevertheless, this is a stupid
solution, the administrator should be fixed, not the computer...)
Andreas
Thorsten Glaser
>@echo off
>set TEMP=c:\blah
>set TMP=c:\blah
>pine
As far as I read his posting, the problem was that this doesn't work.
Binary patching _might_ be a solution.
(I think the code reads like
char *x, lockpath[SOMENUMBER];
if ((x = getenv("SYSTEMROOT")) != NULL) {
strlcpy(lockpath, x, SOMENUMBER);
} else {
strlcpy(lockpath, "C:\\WINDOWS", SOMENUMBER);
}
strlcat(lockpath, "\\TEMP", SOMENUMBER);
- which should be obvious to fix (patch the two strings and
replace SYSTEMROOT by NOTEXISTIN)
>Of course, you have to use a directory where you can write to.
Same here.
//mirabile
Benny Siegert
> On Mon, 13 Dec 2004 19:02:09 +0100, Benny Siegert <bsie...@frankie.66h.42h.de> wrote:
> > I just want to read my e-mail. I am fairly certain the administrator(s)
> > would not change the permissions in the temp directory just for me. The
> > answer would be "Use Eudora for mail, like all the others." But I just
> > switched from Eudora to PC-Pine because it was so awful.
>
> If I understand correctly, you are not able to write to the temp
> directory? (So that means, your system is broken?)
Exactly.
> What about writing some small batch file to start pine? It would look as
> follows:
>
> @echo off
> set TEMP=c:\blah
> set TMP=c:\blah
> pine
I tried, but that does not work. Pine believes that the only safe place
for the lock files is c:\WINNT\Temp. Might be, but I really need to set a
different temp dir.
It would be great if pine could respect TEMP. Normally, it _is_ a
system-wide default value.
--Benny.
Rob Brown
> On Tue, 14 Dec 2004, it was written:
>
>> What about writing some small batch file to start pine? It would look as
>> follows:
>>
>> @echo off
>> set TEMP=c:\blah
>> set TMP=c:\blah
>> pine
>
> I tried, but that does not work. Pine believes that the only safe place
> for the lock files is c:\WINNT\Temp. Might be, but I really need to set a
> different temp dir.
How about (this is a real long shot):
First, create c:\blah\TEMP and then make your batch file like this
@echo off
set WINDIR=c:\blah
pine
Here we are hoping that pine doesn't use anything in the windows tree
except for %windir%/TEMP.
Good luck.
- Rob
--
Rob Brown b r o w n a t g m c l d o t c o m
G. Michaels Consulting Ltd. (866)438-2101 (voice) toll free!
Edmonton (780)438-9343 (voice)
(780)437-3367 (FAX)
http://gmcl.com/
Benny Siegert
> set WINDIR=c:\blah
I didn't try it, but normally this does not work, you cannot set the
windir variable this way. This is because all variables set by command.com
are in uppercase and windir is written in lower case.
--Benny.
mainw...@yourserve.co.uk
@echo off
setlocal
set WINDIR=R:\TEMP
pine.exe
endlocal&EXIT
and it did work in XP (rather than give my LUA access to a restricted location)
Using a v old ver of Pine 4.64, should do something about but can't be bothered