Daniel wrote:
On 11/01/14 21:56, Trane Francks wrote:
On 1/10/14 5:53 PM +0900, Daniel wrote:
On 09/01/14 22:26, Trane Francks wrote:
On 1/9/14 7:34 PM +0900, Daniel wrote:
On 9/01/2014 7:56 PM, Trane Francks wrote:
On 1/9/14 5:13 PM +0900, Daniel wrote:
On 9/01/2014 2:47 AM, Rob wrote:
Daniel <[email protected]> wrote:
It no longer removes the parent.lock file!
Please read it again.
The file is not removed, only the lock on it is released.
The file itself remains, and this is OK.
So what does this mean?? Is SeaMonkey altering the properties
of a
file
(i.e. Read Only or not) without any intervention by me??
Did I write that?
No, I did not.
Nor did I say that you did!
As this is the second time that you post without reading
Read each time!! May not have understood what you have typed, but I
have
read.
what
is written and/or researching what it means, I choose to not
further elaborate on the matter.
Sorry, Rob, I am reading what you type ... and I'm trying to
interpret
that, which, when I read "The file is not removed, only the lock
on it
is released" to me, that is suggesting that the condition of the
file
"Read" property is being altered.
Or is the contents of the file (on my Hard Drive) being altered, or
.....?
Just trying to improve my understanding!
I think what Rob is trying to explain is that older versions used the
file as a kind of static semaphore, where its presence indicated the
lock state and its deletion indicated that things were loosy-goosy.
(He
may not have chosen that term.) Newer versions, on the other hand,
seem
to just place an actual lock on the file itself, while the file's
presence stays static. The lock comes and goes while the file does
not.
As a tech demigod, he shan't elaborate further. His frustration
trumps
your understanding (or lack thereof).
Yes, Trane, I was aware that SM used to create a file called
"parent.lock" (on Windows system), and then removed it as part of the
shut-down system, and I had then become aware of the "parent.lock"
becoming permanently present (was that a ver 1 to ver 2 change??).
I just trying to find out if it just changes the property of the
file or
does it change the content of the file or ....?
No biggee, my system has operating whatever way for some time and done
me no harm.
File locks are akin to a lock on the door. If a file isn't locked, then
an editor can, for example, open a file for writing. If a file is
locked, however, an application that attempts to open said file will
fail to do so. The 'parent.lock' file seems to only be a feature of SM
(Mozilla?) on Windows. On OS X, I do not see the file at all. So,
without having anything concrete to go by, I'll guess that it's only
the
lock itself that's important, not that anything content-wise
changes. If
some locking mechanism is required on OS X, the methodology is handled
differently.
Just FYI, Linux has a ".parentlock" file which, I think, does the same
function as the Windows "parent.lock" file.
Still don't know how either does what it's supposed to achieve!!
Look up the word 'semaphore'. That's what the file is. It is a signal of
a state, triggering specific application behaviour. Nothing more. A lock
on the file tells the application to behave a certain way, as does the
absence of said lock.
"Semaphore Flags is the telegraphy system conveying information at a
distance by means of visual signals ...." Wikipedia!!
So you are suggesting that I should be able to see some difference in
the parent.lock file, dependant on SM running or not??
No! As I've said in other replies, the file Attributes do not change.
There is nothing for a human to see.
Originally, it was the presence (or not) of the file that told SM the
situation.
Now, the file is always present, so it must be something else about the
file which indicates the situation to SM (i.e. indicates the position of
the semaphore flags).
It is SeaMonkey that is setting the lock and reading its presence or
non-presence. As I've said before, a file lock is a Windows function a
programmer can use for various purposes. Perhaps the most common is to
prevent two users from trying to modify a file simultaneously.
<http://msdn.microsoft.com/en-us/library/windows/desktop/aa365202%28v=vs.85%29.aspx>
or
http://tinyurl.com/lh2jogh
If the Windows "Read" property was set or re-set,
that could indicate the situation.
It /could/ but that is not happening.
If the file had content or was a
"null" file, that could indicate the situation.
Again, that is NOT the case.
Maybe, if the Windows
"Hidden" property was set or not could indicate the situation.
Yet again, not applicable in this situation.
"That's what the file is. It is a signal of a state...." How is the
state indicated to human eyes??
It is NOT and there is no need to indicate the state to the user. What
good would it be (in this application) if you /could/ tell whether the
file is locked or not?
--
Ed Mullen
http://edmullen.net/
I used to be indecisive. Now I'm not so sure.
_______________________________________________
support-seamonkey mailing list
[email protected]
https://lists.mozilla.org/listinfo/support-seamonkey
