.#* lock files under X, for files I edit???

[Marc Girod]

Hello, For a few weeks, maybe since I installed 1.7, I have found strange files (nfs lock files?) for files edit. E.g.:

-rwxrwxrwx   1 emagiro  ath          104 May 21 13:57 .#singlebuildweb.pl
-rwxrwxrwx   1 emagiro  ath          104 May 21 13:58 .#singlebuildweb.pl.0
-rwxrwxrwx   1 emagiro  ath          104 May 21 13:58 .#singlebuildweb.pl.1
-rwxrwxrwx   1 emagiro  ath          104 May 21 13:58 .#singlebuildweb.pl.2
-rwxrwxrwx   1 emagiro  ath          104 May 21 13:58 .#singlebuildweb.pl.3
-rwxrwxrwx   1 emagiro  ath          104 May 21 14:02 .#singlebuildweb.pl.4
-rwxrwxrwx   1 emagiro  ath          104 May 21 14:03 .#singlebuildweb.pl.5
-rwxrwxrwx   1 emagiro  ath          104 May 21 14:03 .#singlebuildweb.pl.6
-rwxrwxrwx   1 emagiro  ath          104 May 21 14:04 .#singlebuildweb.pl.7
-rwxrwxrwx   1 emagiro  ath          104 May 21 14:04 .#singlebuildweb.pl.8
-rwxrwxrwx   1 emagiro  ath          104 May 21 14:04 .#singlebuildweb.pl.9

singlebuildweb> cat .#singlebuildweb.pl | tr -d '\000|\376|\377'; echo
![e-mail].6000
singlebuildweb> od -c .#singlebuildweb.pl
0000000   !   <   s   y   m   l   i   n   k   > 377 376   e  \0   m  \0
0000020   a  \0   g  \0   i  \0   r  \0   o  \0   @  \0   E  \0   V  \0
0000040   0  \0   0  \0   1  \0   6  \0   D  \0   4  \0   A  \0   3  \0
0000060   5  \0   0  \0   5  \0   4  \0   .  \0   e  \0   e  \0   m  \0
0000100   e  \0   a  \0   .  \0   e  \0   r  \0   i  \0   c  \0   s  \0
0000120   s  \0   o  \0   n  \0   .  \0   s  \0   e  \0   .  \0   6  \0
0000140   0  \0   0  \0   0  \0  \0  \0
0000150

6000 is of course the port id for X:0.0... Is this a cygwin issue? Thanks, Marc

[Ken Brown-6]

On 5/21/2009 12:00 PM, Marc Girod wrote:
> -rwxrwxrwx   1 emagiro  ath          104 May 21 13:57 .#singlebuildweb.pl
[...]

These look to me like emacs auto-save files.  They should disappear each
time you save the file you're editing.

Ken

--
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/

[Ken Brown-6]

On 5/21/2009 12:23 PM, Ken Brown wrote:
> On 5/21/2009 12:00 PM, Marc Girod wrote:
>> -rwxrwxrwx   1 emagiro  ath          104 May 21 13:57 .#singlebuildweb.pl
> [...]
>
> These look to me like emacs auto-save files.  They should disappear each
> time you save the file you're editing.

Sorry, I think they're emacs lock files.  Auto-save files look like
#filename#.  But they still should disappear each time you save the file.

Ken

--
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/

[Marc Girod]

Ken Brown-6 wrote:

These look to me like emacs auto-save files.  They should disappear each
time you save the file you're editing.

Well, they don't.
The content was slightly blurred, because of my using html format
and forgetting to escape <> characters. As well as a couple of tags.
Marc

[Ken Brown-6]

On 5/21/2009 1:04 PM, Marc Girod wrote:
> Ken Brown-6 wrote:
>> They should disappear each
>> time you save the file you're editing.
>>
> Well, they don't.
> The content was slightly blurred, because of my using html format
> and forgetting to escape <> characters. As well as a couple of tags.

I'm puzzled as I look at your first post again, because emacs file locks
are symbolic links.  Your post shows that the files are ordinary files
containing the string '<symlink>'.  This suggests that you're working in
an environment that doesn't recognize cygwin symlinks.  Could that
somehow explain why they aren't being deleted when you save the file?

According to the emacs documentation:

>    When you make the first modification in an Emacs buffer that is
> visiting a file, Emacs records that the file is "locked" by you.  (It
> does this by creating a specially-named symbolic link in the same
> directory.)  Emacs removes the lock when you save the changes.

Here's an example of an emacs file lock on my system, while I'm editing
'diary':

lrwxrwxrwx  1 kbrown       None      18 May 21 13:15 .#diary ->
kbrown@...

5828 is the PID of my emacs process.  As soon as I save the file, the
symbolic link disappears.

Ken

--
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/

[Thrall, Bryan]

Ken Brown wrote on Thursday, May 21, 2009 1:02 PM:

> On 5/21/2009 1:04 PM, Marc Girod wrote:
>> Ken Brown-6 wrote:
>>> They should disappear each
>>> time you save the file you're editing.
>>>
>> Well, they don't.
>> The content was slightly blurred, because of my using html format
>> and forgetting to escape <> characters. As well as a couple of tags.
>
> I'm puzzled as I look at your first post again, because emacs file

locks
> are symbolic links.  Your post shows that the files are ordinary files
> containing the string '<symlink>'.  This suggests that you're working
in
> an environment that doesn't recognize cygwin symlinks.  Could that
> somehow explain why they aren't being deleted when you save the file?

It's likely that those files *ARE* symlinks; under Cygwin 1.7, symlinks
are implemented as normal files (rather than Windows shortcuts) with a
particular magic number. I'm not sure what Marc was doing with his
original 'cat .# ... | tr' command, but I'm guessing it is removing the
magic number so 'od -c' will print out the contents.

> According to the emacs documentation:
>
>>    When you make the first modification in an Emacs buffer that is
>> visiting a file, Emacs records that the file is "locked" by you.  (It
>> does this by creating a specially-named symbolic link in the same
>> directory.)  Emacs removes the lock when you save the changes.
>
> Here's an example of an emacs file lock on my system, while I'm
editing
> 'diary':
>
> lrwxrwxrwx  1 kbrown       None      18 May 21 13:15 .#diary ->
> kbrown@...
>
> 5828 is the PID of my emacs process.  As soon as I save the file, the
> symbolic link disappears.
>
> Ken



--
Bryan Thrall
FlightSafety International
bryan.thrall@...

--
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/

[Ken Brown-6]

On 5/21/2009 2:16 PM, Thrall, Bryan wrote:
> It's likely that those files *ARE* symlinks; under Cygwin 1.7, symlinks
> are implemented as normal files

Yes, that was my point.  They are cygwin symlinks, but he's examining
them in an environment that doesn't recognize them as such.  Look at his
directory listing:

> -rwxrwxrwx   1 emagiro  ath          104 May 21 13:57 .#singlebuildweb.pl

Ken

--
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/

[Marc Girod]

Ken Brown-6 wrote:

This suggests that you're working in an environment that doesn't recognize cygwin symlinks.

I am in a ClearCase view.
It is an mvfs file system, something built on top of nfs, and
adapted for smb/cifs.
It supports unix links, but maybe cygwin ones are different.
Marc

[Larry Hall (Cygwin)]

Marc Girod wrote:
>
> Ken Brown-6 wrote:
>> This suggests that you're working in an environment that doesn't recognize
>> cygwin symlinks.
>>
> I am in a ClearCase view.
> It is an mvfs file system, something built on top of nfs, and
> adapted for smb/cifs.
> It supports unix links, but maybe cygwin ones are different.

Yes, they are different and the default technique for 1.7 is different
than for 1.5:

<http://cygwin.com/1.7/faq/faq.using.html#faq.using.symlinkstoppedworking>
<http://cygwin.com/1.7/faq/faq.using.html#faq.using.symlinks-samba>


--
Larry Hall                              http://www.rfk.com
RFK Partners, Inc.                      [phone] - RFK Office
216 Dalton Rd.                          [phone] - FAX
Holliston, MA 01746

_____________________________________________________________________

A: Yes.
 > Q: Are you sure?
 >> A: Because it reverses the logical flow of conversation.
 >>> Q: Why is top posting annoying in email?

--
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/

[Marc Girod]

Ken Brown-6 wrote:

Here's an example of an emacs file lock on my system, while I'm editing
'diary':

It seems thus that whereas mvfs was able to cope with cygwin symlinks
so far, now it stopped, probably because of the use of utf8.
I do not have access to the NetApp filer from where the view storage is
exported, to modify the export options, nor to the nis server to change
the parameters used in the automount pages.

Reading the source code, filelock.c, I can see that the only thing I could
do to avoid creating those lock files, would be to set purify_flag to t.

I guess there might be unwanted side-effects(?)
Buffer local when working in a view?

I am afraid that this locking (spurious in a ClearCase view which
already uses its own locking mechanism) may have other impacts than
the esthetic one of leaving those files.
Especially, it may be the cause of the horrendous delays I get when
working from home over a VPN connection...

[Ken Brown-6]

On 5/22/2009 10:22 AM, Marc Girod wrote:
> It seems thus that whereas mvfs was able to cope with cygwin symlinks
> so far, now it stopped

What about adding winsymlinks to your CYGWIN environment variable to go
back to the old style of symlink?  See

        http://cygwin.com/1.7/cygwin-ug-net/using-cygwinenv.html

Ken

--
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/

[Marc Girod]

Ken Brown-6 wrote:

On 5/22/2009 10:22 AM, Marc Girod wrote:
What about adding winsymlinks to your CYGWIN environment variable to go
back to the old style of symlink?

Thanks. I'll try that.
However, the speed penalty over vpn was there earlier.
It may not depend on whether the files are deleted or not
(the code to delete them does a plain unlink, so I cannot
why it fails, in fact...).
I have to test this!

This page contained other information that I had
overlooked. E.g. something concerning case preservation
which I had noticed in file completion.
MVFS is also case preserving (sharing with unix), so
offering to do a lowercase for completion is not welcome.

Thanks,
Marc

[Marc Girod]

Marc Girod wrote:

Thanks. I'll try that.

That was: 'CYGWIN=winsymlinks tty'
The result is not fully satisfying.
E.g.:

  lrwxrwxrwx  1 emagiro EEI-ATusers    45 Jul 14 11:57 .#common.mk -> [e-mail].4708

in a dired buffer, and which I cannot remove:

makesystem> rm -f .\#*
rm: cannot remove `.#common.mk': Permission denied

The process is still running indeed, but the lock/link doesn't
go away when I kill the buffer, or even exit emacs, as shown
with this one (elsewhere):

bin> ls -la .#select_config.pl
lrwxrwxrwx 1 emagiro EEI-ATusers 45 Jun 26 16:09 .#select_config.pl -> [e-mail].4620

This process has gone long ago!
The reason is the same I guess as the one for which I cannot
remove the link from the command line, and has to do either
with the fact the file system is CIFS mounted from a NetApp
filer, or with the fact this is not its real name.
I can access this filesystem from unix as well, and there, it
looks different, and I can remove it:

makesystem> ll .\#*
-r-xr-xr-x   1 emagiro  at1          299 Jul 14 11:57 .#common.mk.lnk
makesystem> rm -f .\#*
makesystem> ll .\#*
.#*: No such file or directory

Gone now from the cygwin view as well.
But I understand this is the *old* symlink implementation,
as a file with a funny name, instead of as a reall sym link,
incurring the performance penalties, etc.

So, my next move now will be to set a find-file-hook to
check whether I am in a ClearCase view, and if so, to
make purify_flag buffer-local and set it to t.

I'll report my results...

Marc

[Marc Girod]

Marc Girod wrote:

I'll report my results...

Here is what I did, to make it practical:

(defun clearcase-no-lock()
  "Under ClearCase, in Cygwin, do not create lock symlinks.
Either format (old: Windows shortcuts; new: real symlinks with utf name) are
bad for different reasons.
The only way to prevent this is to set the purify_flag used by emacs while
dumping...
This function is intened as a find-file-hook."
  (let ((fname (buffer-file-name)))
    (if (file-accessible-directory-p (concat fname "@@"))
        (set (make-local-variable 'purify_flag) t))))
(add-hook 'find-file-hook 'clearcase-no-lock)


Note that this would work only for 'elements' (i.e. not for
view private files) since their version tree opens as a
directory under the '@@' filename extension.
I guess it is a faster check than invoking cleartool...

Marc

[Marc Girod]

Just two fixes for now:

Marc Girod wrote:

This function is intened as a find-file-hook."
...
        (set (make-local-variable 'purify_flag) t))))

intended
purify-flag

Marc

[Eric Blake]

> (set (make-local-variable 'purify_flag) t))))

Setting purify-flag wasn't working for me (emacs gave a message
about an assertion failure).  And my attempt to write an advice
didn't seem to work any better (unless I didn't do it correctly):

(defadvice lock-buffer (around clearcase-no-lock activate)
  "Under ClearCase, in Cygwin, do not create lock symlinks.
Either format (old: Windows shortcuts; new: real symlinks with utf name) are
bad for different reasons."
       (unless (file-accessible-directory-p (concat (buffer-file-name) "@@"))
         ad-do-it))

Rather, it seems that the REAL problem is that cygwin1.dll cannot
recognize attempts to create symlinks on the clearcase MVFS file system.

$ df -T .
Filesystem    Type   1K-blocks      Used Available Use% Mounted on
M:/u_fabt_eblake
           unknown     1024000    512000    512000  50% /project/fabt
$ volinfo .
Device Type        : 7
Characteristics    : 10
Volume Name        : <CCase>
Serial Number      : 36984713
Max Filenamelength : 255
Filesystemname     : <MVFS>
Flags              : 3
  FILE_CASE_SENSITIVE_SEARCH  : TRUE
  FILE_CASE_PRESERVED_NAMES   : TRUE
  FILE_UNICODE_ON_DISK        : FALSE
  FILE_PERSISTENT_ACLS        : FALSE
  FILE_FILE_COMPRESSION       : FALSE
  FILE_VOLUME_QUOTAS          : FALSE
  FILE_SUPPORTS_SPARSE_FILES  : FALSE
  FILE_SUPPORTS_REPARSE_POINTS: FALSE
  FILE_SUPPORTS_REMOTE_STORAGE: FALSE
  FILE_VOLUME_IS_COMPRESSED   : FALSE
  FILE_SUPPORTS_OBJECT_IDS    : FALSE
  FILE_SUPPORTS_ENCRYPTION    : FALSE
  FILE_NAMED_STREAMS          : FALSE
  FILE_READ_ONLY_VOLUME       : FALSE
  FILE_SEQUENTIAL_WRITE_ONCE  : FALSE
  FILE_SUPPORTS_TRANSACTIONS  : FALSE
$ touch foo
$ ln -s foo bar
$ readlink bar || echo $?
1
$ cat bar
!<symlink>~foo
$ file bar
bar: data

Maybe we should be trying to change cygwin to cause
symlink() to fail with a proper errno on MVFS, and then
revisit the emacs side of the equation to see how emacs
handles failure to create a symlink when errno is ENOSYS
(or whatever errno cygwin uses).  Or maybe it is just
a matter of detecting that if the file system does not
support DOS attributes (which are essential in creating
new-style symlinks), that an old-style symlink must be
created on that filesystem.

--
Eric Blake

[Corinna Vinschen-2]

On Jul 15 09:49, Eric Blake wrote:

> Rather, it seems that the REAL problem is that cygwin1.dll cannot
> recognize attempts to create symlinks on the clearcase MVFS file system.
>
> $ df -T .
> Filesystem    Type   1K-blocks      Used Available Use% Mounted on
> M:/u_fabt_eblake
>            unknown     1024000    512000    512000  50% /project/fabt
> $ volinfo .
> Device Type        : 7
> Characteristics    : 10
> Volume Name        : <CCase>
> Serial Number      : 36984713
> Max Filenamelength : 255
> Filesystemname     : <MVFS>
> Flags              : 3
>   FILE_CASE_SENSITIVE_SEARCH  : TRUE
>   FILE_CASE_PRESERVED_NAMES   : TRUE
>   FILE_UNICODE_ON_DISK        : FALSE
>   FILE_PERSISTENT_ACLS        : FALSE
>   FILE_FILE_COMPRESSION       : FALSE
>   FILE_VOLUME_QUOTAS          : FALSE
>   FILE_SUPPORTS_SPARSE_FILES  : FALSE
>   FILE_SUPPORTS_REPARSE_POINTS: FALSE
>   FILE_SUPPORTS_REMOTE_STORAGE: FALSE
>   FILE_VOLUME_IS_COMPRESSED   : FALSE
>   FILE_SUPPORTS_OBJECT_IDS    : FALSE
>   FILE_SUPPORTS_ENCRYPTION    : FALSE
>   FILE_NAMED_STREAMS          : FALSE
>   FILE_READ_ONLY_VOLUME       : FALSE
>   FILE_SEQUENTIAL_WRITE_ONCE  : FALSE
>   FILE_SUPPORTS_TRANSACTIONS  : FALSE
> $ touch foo
> $ ln -s foo bar
> $ readlink bar || echo $?
> 1
> $ cat bar
> !<symlink>~foo
> $ file bar
> bar: data
>
> Maybe we should be trying to change cygwin to cause
> symlink() to fail with a proper errno on MVFS, and then
> revisit the emacs side of the equation to see how emacs
> handles failure to create a symlink when errno is ENOSYS
> (or whatever errno cygwin uses).  Or maybe it is just
> a matter of detecting that if the file system does not
> support DOS attributes (which are essential in creating
> new-style symlinks), that an old-style symlink must be
> created on that filesystem.

That's something we can do.  I'll look into it.


Corinna

--
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

[Marc Girod]

Eric Blake wrote:

> (set (make-local-variable 'purify_flag) t))))

Setting purify-flag wasn't working for me (emacs gave a message
about an assertion failure).

Huh? Nothing like that here.
In fact, it works...
Wait:
- I still have the 'CYGWIN=winsymlinks' setting --although unsetting it doesn't affect
- there was this typo on purify_flag --but I assume you saw it: dash, not underscore

Eric Blake wrote:

Rather, it seems that the REAL problem is that cygwin1.dll cannot
recognize attempts to create symlinks on the clearcase MVFS file system.

OK.
However, it is and was able to create something.
My problem has been that it wasn't able to remove them.

Eric Blake wrote:

Maybe we should be trying to change cygwin to cause
symlink() to fail with a proper errno on MVFS, and then
revisit the emacs side of the equation to see how emacs
handles failure to create a symlink when errno is ENOSYS
(or whatever errno cygwin uses).  Or maybe it is just
a matter of detecting that if the file system does not
support DOS attributes (which are essential in creating
new-style symlinks), that an old-style symlink must be
created on that filesystem.

OK again. Now you are already much deeper than I ever
was in the causes.
The MVFS doesn't support DOS attributes?
I have no clue about that.
How may I check this? Interesting...

makesystem> type volinfo
bash: type: volinfo: not found
makesystem> cygcheck -p volinfo
Found 0 matches for volinfo.
makesystem> df -T .
Filesystem    Type   1K-blocks      Used Available Use% Mounted on
X:         unknown    81920000  30720000  51200000  38% /cygdrive/x

Note: I am one version behind with cygwin: 1.7.0-50

makesystem> touch foo
makesystem> ln -s foo bar
makesystem> readlink bar || echo $?
foo
makesystem> file bar
bar: symbolic link to `foo'
makesystem> ll bar
lrwxrwxrwx 1 emagiro EEI-ATusers 3 Jul 15 18:56 bar -> foo
makesystem> rm bar
rm: cannot remove `bar': Permission denied
makesystem> ct pwv
Working directory view: emagiro_86
Set view: emagiro_86
makesystem> export CYGWIN=tty
makesystem> ln -s foo zoo
makesystem> readlink zoo || echo $?
1
makesystem> ll zoo
-rw-r--r-- 1 emagiro EEI-ATusers 20 Jul 15 18:58 zoo
makesystem> file zoo
zoo: data
makesystem> od -c zoo
0000000   !   <   s   y   m   l   i   n   k   > 377 376   f  \0   o  \0
0000020   o  \0  \0  \0
0000024
makesystem> rm zoo
makesystem>

I confirm that my find-file-hook works.
I didn't want to restart my emacs, but I tried with:

(setenv "CYGWIN" "tty")
"tty"

in the *scratch* buffer, and opening an existing checked-out file.
No lock created.

Marc

[Corinna Vinschen-2]

On Jul 15 11:08, Marc Girod wrote:
> OK again. Now you are already much deeper than I ever
> was in the causes.
> The MVFS doesn't support DOS attributes?
> I have no clue about that.
> How may I check this? Interesting...

Try this on the MVFS FS:

$ touch foo
$ attrib foo
A        X:\foo
$ attrib +r +s foo
$ attrib foo
A  S R   X:\foo

If you don't get the above result, MVFS doesn't support DOS attributes,
or it only supports them partially.  It would be helpful to get this
information exactly from somebody using MVFS.


Corinna

--
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

[Marc Girod]

Marc Girod wrote:

Just two fixes for now:

My emacs crashed (Memory Full).
I don't know whether this may be related.
It had not done so for long.
This might well be a side-effect of this purify-flag...
Maybe I could set it to nil on some later function?

Otherwise, my hack seems to work well for me.
Only, I need to load packages from a non-ClearCase buffer,
because load will object if called 'under dumping'...

Marc