auta-save files cause Aquamacs to hang

[Pete Siemsen]

In my group at work, we share a Linux server that contains hundreds of  
files. We have many Windows users in the group, so we use SAMBA to  
share the filesystems on the server.  I SAMBA-mount the server's  
filesystems on my Mac.  I have no trouble accessing the files on the  
server, using paths that start with '/Volumes/'.

No problem, it's worked for years, except now I'm trying to stop using  
TextMate and start using Aquamacs.

Aquamacs wants to write auto-save files, with names that start with  
'.#', in the same directory as each file being edited.  Aquamacs is  
supposed to delete the auto-save files whenever I close the real  
file.  For some reason, it's not happening. The auto-save files aren't  
being deleted.  When I try to re-edit a file that has an auto-save  
file, Aquamacs lets me open it, but as soon as I try to modify the  
buffer, Aquamacs hangs.  I get the spinning ball of death and end up  
having to 'Force Quit' Aquamacs.  I can manually delete the auto-save  
file, restart Aquamacs, and edit the real file again.

-- Pete

_______________________________________________
Aquamacs-devel mailing list
Aquamacs-devel@...
http://lists.aquamacs.org/mailman/listinfo.cgi/aquamacs-devel

[davidswelt]

What version?
Have you tried to turn off auto-save?

On Sep 28, 2009, at 5:31 PM, Pete Siemsen wrote:

> In my group at work, we share a Linux server that contains hundreds  
> of files. We have many Windows users in the group, so we use SAMBA  
> to share the filesystems on the server.  I SAMBA-mount the server's  
> filesystems on my Mac.  I have no trouble accessing the files on the  
> server, using paths that start with '/Volumes/'.
>
> No problem, it's worked for years, except now I'm trying to stop  
> using TextMate and start using Aquamacs.
>
> Aquamacs wants to write auto-save files, with names that start with  
> '.#', in the same directory as each file being edited.  Aquamacs is  
> supposed to delete the auto-save files whenever I close the real  
> file.  For some reason, it's not happening. The auto-save files  
> aren't being deleted.  When I try to re-edit a file that has an auto-
> save file, Aquamacs lets me open it, but as soon as I try to modify  
> the buffer, Aquamacs hangs.  I get the spinning ball of death and  
> end up having to 'Force Quit' Aquamacs.  I can manually delete the  
> auto-save file, restart Aquamacs, and edit the real file again.
>
> -- Pete

_______________________________________________
Aquamacs-devel mailing list
Aquamacs-devel@...
http://lists.aquamacs.org/mailman/listinfo.cgi/aquamacs-devel

[Pete Siemsen]

I'm using version  "2.0preview2".

My attempt to turn off auto-save didn't work.  Given an existing large  
(453789 bytes) file named abc.txt on a remote system, I did this:

1. On my Mac, exited Aquamacs, just to set up state for the test
2. On the remote system, manually deleted the leftover auto-save file  
named .#abc.txt, just to set up state for the test
3. On my Mac, started Aquamacs
4. Did C-x C-f to open the remote file named /Volumes/xxx/abc.txt
5. Did M-x auto-save-mode to toggle auto-save off.  Aquamacs said  
"Auto-save off (in this buffer)"
6. Modified the buffer.
7. On the remote system, did "ls -alt" and found

lrwxrwxrwx  1 siemsen datacomm      33 Sep 30 15:19 .#abc.txt -> siemsen@...

My Mac is named "galway".  So Aquamacs created the auto-save file,  
despite what I did in step 5.  This seems to be a bug.

8. On my Mac, did C-x C-s
9. On the remote system, did "ls -alt" and found a newly written  
abc.txt and also .#abc.txt

So Aquamacs didn't delete the auto-save file.  This seems to be a  
bug.  My delete-auto-save-files variable has the default value of 't'.

10. On my Mac, restarted Aquamacs.
11. Opened the remote file again.
12. Tried to modify the buffer.  Aquamacs hung with the spinning ball  
of death.  I had to use Force Quit to kill it.

I get different behavior if I replace step 10 with "C-x k".  If I do  
that, Aquamacs behaves normally in step 12.

BTW, I tried to figure this out, with no luck.  The GNU Emacs manual  
says that the names of auto-save files are constructed using the  
contents of auto-save-file-name-transforms.  In Aquamacs, that  
variable seems to want to put auto-save files in a directory named /
var/folders, which doesn't exist on my Mac.  I can only assume that  
Aquamacs has it's own mechanism for creating auto-save files, and  
ignores auto-save-file-name-transforms.

-- Pete


On Sep 28, 2009, at 5:18 PM, David Reitter wrote:

> What version?
> Have you tried to turn off auto-save?
>
> On Sep 28, 2009, at 5:31 PM, Pete Siemsen wrote:
>
>> In my group at work, we share a Linux server that contains hundreds  
>> of files. We have many Windows users in the group, so we use SAMBA  
>> to share the filesystems on the server.  I SAMBA-mount the server's  
>> filesystems on my Mac.  I have no trouble accessing the files on  
>> the server, using paths that start with '/Volumes/'.
>>
>> No problem, it's worked for years, except now I'm trying to stop  
>> using TextMate and start using Aquamacs.
>>
>> Aquamacs wants to write auto-save files, with names that start with  
>> '.#', in the same directory as each file being edited.  Aquamacs is  
>> supposed to delete the auto-save files whenever I close the real  
>> file.  For some reason, it's not happening. The auto-save files  
>> aren't being deleted.  When I try to re-edit a file that has an  
>> auto-save file, Aquamacs lets me open it, but as soon as I try to  
>> modify the buffer, Aquamacs hangs.  I get the spinning ball of  
>> death and end up having to 'Force Quit' Aquamacs.  I can manually  
>> delete the auto-save file, restart Aquamacs, and edit the real file  
>> again.
>>
>> -- Pete
>
> _______________________________________________
> Aquamacs-devel mailing list
> Aquamacs-devel@...
> http://lists.aquamacs.org/mailman/listinfo.cgi/aquamacs-devel

_______________________________________________
Aquamacs-devel mailing list
Aquamacs-devel@...
http://lists.aquamacs.org/mailman/listinfo.cgi/aquamacs-devel

[Pete Siemsen]

I still have this problem, which I previously mistakenly referred to as a problem with auto-save files.  It's really a problem with lock files.  It happens in version "2.0preview2" and "2.0dev".

The problem is: when editing network-mounted files, Aquamacs doesn't process lock files correctly.  If I open an existing network-mounted file named abc.txt, Aquamacs creates a lock file in the same directory as the source file, on the remote system.  The lock file is a symbolic link named ".#abc.txt".  An ls command shows

    .#abc.txt -> siemsen@...

As described in the "File Locks" section of the "GNU Emacs Lisp Reference Manual", the link points back to the Aquamacs process on my Mac, which is named galway.scd.ucar.edu.  The process is running as user siemsen, and the PID is 12194.

So far, so good.  The problem is that when I finish editing the file, the lock file isn't deleted.  When I try to edit the file later, Aquamacs lets me open file, but hangs the instant I try to modify it.  Aquamacs locks up with the spinning wheel of death, and I have to Force Quit.  If I then go to the remote system and manually delete the lock file, Aquamacs can edit the file with no problems.

I don't see lock files created when I edit files on my local system - only network-mounted files.  The manual says I should be able to test whether a file is locked with file-locked-p, but that function doesn't seem to be implemented in Aquamacs.  Could it be that Aquamacs doesn't implement file locks, but something different happens with network-mounted files?

FWIW, I found the code for filelock.c, which implements file-locked-p and unlock-buffer.  I see that unlock-buffer calls the C function named unlock_file, which uses a call to unlink to delete lock files.  Perhaps unlock_file should check the status code returned by unlink.

This is easily repeatable, and quite annoying.  I'd be happy to supply the dump from Force Quit if it would help.

- Pete

Begin forwarded message:

From: siemsen@...

Date: September 30, 2009 3:56:27 PM MDT

To: Aquamacs Developers <aquamacs-devel@...>

Subject: Re: [Aquamacs-devel] auta-save files cause Aquamacs to hang

Reply-To: siemsen@..., Aquamacs Developers <aquamacs-devel@...>

I'm using version  "2.0preview2".

My attempt to turn off auto-save didn't work.  Given an existing large (453789 bytes) file named abc.txt on a remote system, I did this:

1. On my Mac, exited Aquamacs, just to set up state for the test
2. On the remote system, manually deleted the leftover auto-save file named .#abc.txt, just to set up state for the test
3. On my Mac, started Aquamacs
4. Did C-x C-f to open the remote file named /Volumes/xxx/abc.txt
5. Did M-x auto-save-mode to toggle auto-save off.  Aquamacs said "Auto-save off (in this buffer)"
6. Modified the buffer.
7. On the remote system, did "ls -alt" and found

lrwxrwxrwx  1 siemsen datacomm      33 Sep 30 15:19 .#abc.txt -> siemsen@...

My Mac is named "galway".  So Aquamacs created the auto-save file, despite what I did in step 5.  This seems to be a bug.

8. On my Mac, did C-x C-s
9. On the remote system, did "ls -alt" and found a newly written abc.txt and also .#abc.txt

So Aquamacs didn't delete the auto-save file.  This seems to be a bug.  My delete-auto-save-files variable has the default value of 't'.

10. On my Mac, restarted Aquamacs.
11. Opened the remote file again.
12. Tried to modify the buffer.  Aquamacs hung with the spinning ball of death.  I had to use Force Quit to kill it.

I get different behavior if I replace step 10 with "C-x k".  If I do that, Aquamacs behaves normally in step 12.

BTW, I tried to figure this out, with no luck.  The GNU Emacs manual says that the names of auto-save files are constructed using the contents of auto-save-file-name-transforms.  In Aquamacs, that variable seems to want to put auto-save files in a directory named /var/folders, which doesn't exist on my Mac.  I can only assume that Aquamacs has it's own mechanism for creating auto-save files, and ignores auto-save-file-name-transforms.

-- Pete


On Sep 28, 2009, at 5:18 PM, David Reitter wrote:

What version?

Have you tried to turn off auto-save?

On Sep 28, 2009, at 5:31 PM, Pete Siemsen wrote:

In my group at work, we share a Linux server that contains hundreds of files. We have many Windows users in the group, so we use SAMBA to share the filesystems on the server.  I SAMBA-mount the server's filesystems on my Mac.  I have no trouble accessing the files on the server, using paths that start with '/Volumes/'.

No problem, it's worked for years, except now I'm trying to stop using TextMate and start using Aquamacs.

Aquamacs wants to write auto-save files, with names that start with '.#', in the same directory as each file being edited.  Aquamacs is supposed to delete the auto-save files whenever I close the real file.  For some reason, it's not happening. The auto-save files aren't being deleted.  When I try to re-edit a file that has an auto-save file, Aquamacs lets me open it, but as soon as I try to modify the buffer, Aquamacs hangs.  I get the spinn
_______________________________________________
Aquamacs-devel mailing list
Aquamacs-devel@...
http://lists.aquamacs.org/mailman/listinfo.cgi/aquamacs-devel

[davidswelt]

Pete,
that's a pretty good analysis so far.
Yes, the dump would help.  You can also run Aquamacs under gdb and  
interrupt the process when the hang occurs.  "bt" gives you a backtrace.
I would run it with "run -Q" from gdb.

Also, does this not occur with 1.9?

Have you tested it only on SMB shares, or also on normal AFP ones?

- David

On Oct 20, 2009, at 4:59 PM, siemsen@... wrote:

> I still have this problem, which I previously mistakenly referred to  
> as a problem with auto-save files.  It's really a problem with lock  
> files.  It happens in version "2.0preview2" and "2.0dev".
>
> The problem is: when editing network-mounted files, Aquamacs doesn't  
> process lock files correctly.  If I open an existing network-mounted  
> file named abc.txt, Aquamacs creates a lock file in the same  
> directory as the source file, on the remote system.  The lock file  
> is a symbolic link named ".#abc.txt".  An ls command shows
>
>     .#abc.txt -> siemsen@...
>
> As described in the "File Locks" section of the "GNU Emacs Lisp  
> Reference Manual", the link points back to the Aquamacs process on  
> my Mac, which is named galway.scd.ucar.edu.  The process is running  
> as user siemsen, and the PID is 12194.
>
> So far, so good.  The problem is that when I finish editing the  
> file, the lock file isn't deleted.  When I try to edit the file  
> later, Aquamacs lets me open file, but hangs the instant I try to  
> modify it.  Aquamacs locks up with the spinning wheel of death, and  
> I have to Force Quit.  If I then go to the remote system and  
> manually delete the lock file, Aquamacs can edit the file with no  
> problems.
>
> I don't see lock files created when I edit files on my local system  
> - only network-mounted files.  The manual says I should be able to  
> test whether a file is locked with file-locked-p, but that function  
> doesn't seem to be implemented in Aquamacs.  Could it be that  
> Aquamacs doesn't implement file locks, but something different  
> happens with network-mounted files?
>
> FWIW, I found the code for filelock.c, which implements file-locked-
> p and unlock-buffer.  I see that unlock-buffer calls the C function  
> named unlock_file, which uses a call to unlink to delete lock  
> files.  Perhaps unlock_file should check the status code returned by  
> unlink.
>
> This is easily repeatable, and quite annoying.  I'd be happy to  
> supply the dump from Force Quit if it would help.
>
> - Pete
>
>
> Begin forwarded message:
>
>> From: siemsen@...
>> Date: September 30, 2009 3:56:27 PM MDT
>> To: Aquamacs Developers <aquamacs-devel@...>
>> Subject: Re: [Aquamacs-devel] auta-save files cause Aquamacs to hang
>> Reply-To: siemsen@..., Aquamacs Developers <aquamacs-devel@...
>> >
>>
>> I'm using version  "2.0preview2".
>>
>> My attempt to turn off auto-save didn't work.  Given an existing  
>> large (453789 bytes) file named abc.txt on a remote system, I did  
>> this:
>>
>> 1. On my Mac, exited Aquamacs, just to set up state for the test
>> 2. On the remote system, manually deleted the leftover auto-save  
>> file named .#abc.txt, just to set up state for the test
>> 3. On my Mac, started Aquamacs
>> 4. Did C-x C-f to open the remote file named /Volumes/xxx/abc.txt
>> 5. Did M-x auto-save-mode to toggle auto-save off.  Aquamacs said  
>> "Auto-save off (in this buffer)"
>> 6. Modified the buffer.
>> 7. On the remote system, did "ls -alt" and found
>>
>> lrwxrwxrwx  1 siemsen datacomm      33 Sep 30 15:19 .#abc.txt ->  
>> siemsen@...
>>
>> My Mac is named "galway".  So Aquamacs created the auto-save file,  
>> despite what I did in step 5.  This seems to be a bug.
>>
>> 8. On my Mac, did C-x C-s
>> 9. On the remote system, did "ls -alt" and found a newly written  
>> abc.txt and also .#abc.txt
>>
>> So Aquamacs didn't delete the auto-save file.  This seems to be a  
>> bug.  My delete-auto-save-files variable has the default value of  
>> 't'.
>>
>> 10. On my Mac, restarted Aquamacs.
>> 11. Opened the remote file again.
>> 12. Tried to modify the buffer.  Aquamacs hung with the spinning  
>> ball of death.  I had to use Force Quit to kill it.
>>
>> I get different behavior if I replace step 10 with "C-x k".  If I  
>> do that, Aquamacs behaves normally in step 12.
>>
>> BTW, I tried to figure this out, with no luck.  The GNU Emacs  
>> manual says that the names of auto-save files are constructed using  
>> the contents of auto-save-file-name-transforms.  In Aquamacs, that  
>> variable seems to want to put auto-save files in a directory named /
>> var/folders, which doesn't exist on my Mac.  I can only assume that  
>> Aquamacs has it's own mechanism for creating auto-save files, and  
>> ignores auto-save-file-name-transforms.
>>
>> -- Pete
>>
>>
>> On Sep 28, 2009, at 5:18 PM, David Reitter wrote:
>>
>>> What version?
>>> Have you tried to turn off auto-save?
>>>
>>> On Sep 28, 2009, at 5:31 PM, Pete Siemsen wrote:
>>>
>>>> In my group at work, we share a Linux server that contains  
>>>> hundreds of files. We have many Windows users in the group, so we  
>>>> use SAMBA to share the filesystems on the server.  I SAMBA-mount  
>>>> the server's filesystems on my Mac.  I have no trouble accessing  
>>>> the files on the server, using paths that start with '/Volumes/'.
>>>>
>>>> No problem, it's worked for years, except now I'm trying to stop  
>>>> using TextMate and start using Aquamacs.
>>>>
>>>> Aquamacs wants to write auto-save files, with names that start  
>>>> with '.#', in the same directory as each file being edited.  
>>>> Aquamacs is supposed to delete the auto-save files whenever I  
>>>> close the real file.  For some reason, it's not happening. The  
>>>> auto-save files aren't being deleted.  When I try to re-edit a  
>>>> file that has an auto-save file, Aquamacs lets me open it, but as  
>>>> soon as I try to modify the buffer, Aquamacs hangs.  I get the  
>>>> spinn_______________________________________________
>>>> Aquamacs-devel mailing list
>>>> Aquamacs-devel@...
>>>> http://lists.aquamacs.org/mailman/listinfo.cgi/aquamacs-devel

_______________________________________________
Aquamacs-devel mailing list
Aquamacs-devel@...
http://lists.aquamacs.org/mailman/listinfo.cgi/aquamacs-devel

[Pete Siemsen]

Some more information:

In previous messages, I wrote that I to avoid having Aquamacs hang, I could go to the remote system and delete the lock file, and then Aquamacs would be able to edit the file associated with the lock file.  That's true, but I deleted the lock file by executing an "rm" command on the remote system.  Today it occurred to me that since the hang is occurring on a call to unlink, I might be able to hang a Terminal session on my local Mac by using an "rm" command, specifying the remote file.  Here's a "before-and-after" executed on my Mac named okapi, with a remote file named index.shtml and it's Aquamacs-generated lock file:

okapi-2$ ls -alt /Volumes/web/nets/

total 6292

drwxrwxr-x   2 siemsen  siemsen    16384 Oct 22 04:23 .

-rwxrw-r--   1 siemsen  siemsen     3101 Oct 22 04:23 index.shtml

lrwxrwxrwx   1 siemsen  siemsen       27 Oct 22 04:23 .#index.shtml -> siemsen@...

drwxrwxr-x  13 siemsen  siemsen    16384 Oct 19 11:51 ..

okapi-2$ rm /Volumes/web/nets/.#index.shtml 

okapi-2$ ls -alt /Volumes/web/nets/

total 6292

drwxrwxr-x   2 siemsen  siemsen    16384 Oct 22 04:24 .

-rwxrw-r--   1 siemsen  siemsen     3101 Oct 22 04:23 index.shtml

lrwxrwxrwx   1 siemsen  siemsen       27 Oct 22 04:23 .#index.shtml -> siemsen@...

drwxrwxr-x  13 siemsen  siemsen    16384 Oct 19 11:51 ..

okapi-2$ 

Interesting - the rm command didn't work, but didn't hang, and didn't give an error message.  It seems that this shows some kind of problem with SMB sharing of symbolic links, external to Aquamacs.  Perhaps I should try to take this to the maintainers of the SMB code?

-- Pete

_______________________________________________
Aquamacs-devel mailing list
Aquamacs-devel@...
http://lists.aquamacs.org/mailman/listinfo.cgi/aquamacs-devel

[Pete Siemsen]

David,

With gdb on "2.0preview2", here's the backtrace:

(gdb) bt
#0  0x94d5da76 in unlink ()
#1  0x000f864f in current_lock_owner ()
#2  0x000f86e7 in lock_if_free ()
#3  0x000f8926 in lock_file ()
#4  0x000fe2ad in prepare_to_modify_buffer ()
#5  0x000fd6be in del_range_1 ()
#6  0x000fd625 in del_range ()
#7  0x00116dfa in Fdelete_char ()
#8  0x00169c15 in Ffuncall ()
#9  0x00164532 in Fcall_interactively ()
#10 0x00169c48 in Ffuncall ()
#11 0x00169704 in call3 ()
#12 0x000daa38 in Fcommand_execute ()
#13 0x000c9e31 in command_loop_1 ()
#14 0x00167030 in internal_condition_case ()
#15 0x000c7ca2 in command_loop_2 ()
#16 0x001669c1 in internal_catch ()
#17 0x000c7c2b in command_loop ()
#18 0x000c71ff in recursive_edit_1 ()
#19 0x000c7408 in Frecursive_edit ()
#20 0x000c5710 in main ()
(gdb)


Yes, it also occurs with 1.9.  Using 1.9, here's the top part of a dump after a Force Quit:

Date/Time:      2009-10-21 08:49:09 -0600
OS Version:     10.5.8 (Build 9L30)
Architecture:   i386
Report Version: 4

Command:        Aquamacs
Path:           /Applications/Aquamacs Emacs.app/Contents/MacOS/Aquamacs Emacs
Version:        Aquamacs 1.9, GNU Emacs 22 (1.9)
Parent:         launchd [125]

PID:            4883
Event:          hang
Time:           8.02s
Steps:          48


Process:        Aquamacs Emacs [4883]
Path:           /Applications/Aquamacs Emacs.app/Contents/MacOS/Aquamacs Emacs

 ADDRESS         BINARY
 00001000        /Applications/Aquamacs Emacs.app/Contents/MacOS/Aquamacs Emacs
 01781000        /System/Library/PrivateFrameworks/URLMount.framework/URLMount
 020eb000        /System/Library/CoreServices/RawCamera.bundle/Contents/MacOS/RawCamera
 02464000        /System/Library/Filesystems/URLMount/smb.URLMounter/Contents/MacOS/smb

 Thread id:      8f16998
 User stack:
   48 _prepare_to_modify_buffer + 383 (in Aquamacs Emacs) [0xc525a]
     27 ___unlink + 10 (in libSystem.B.dylib) [0x94d5da76]
     11 ___symlink + 10 (in libSystem.B.dylib) [0x94d9879e]
     10 ___readlink + 10 (in libSystem.B.dylib) [0x94d55a0e]
 Kernel stack:
   48 _unix_syscall + 572 [0x3e3a7f]
     27 _unlink + 113 [0x1e55b1]
       27 _undelete + 665 [0x1e5403]
         16 _VNOP_REMOVE + 119 [0x1f5c53]
           16 com.apple.filesystems.smbfs (1.4.6) + 69064 [0x5b3bcdc8]
             16 com.apple.filesystems.smbfs (1.4.6) + 68698 [0x5b3bcc5a]
               15 com.apple.filesystems.smbfs (1.4.6) + 34555 [0x5b3b46fb]
                 15 com.apple.filesystems.smbfs (1.4.6) + 125137 [0x5b3ca8d1]
                   15 com.apple.filesystems.smbfs (1.4.6) + 124651 [0x5b3ca6eb]
                     15 com.apple.filesystems.smbfs (1.4.6) + 122984 [0x5b3ca068]
                       15 _msleep + 157 [0x3863e8]
                         15 _uiomove + 608 [0x38600a]
                           15 _lck_mtx_sleep_deadline + 104 [0x130e26]
                             15 _thread_block + 33 [0x136f20]
                               12 _thread_continue + 1180 [0x136cb3]
                               3 _thread_block_reason + 135 [0x136e7c]
                                 3 _thread_setrun + 3597 [0x136217]
                                   3 _machine_idle + 271 [0x1ac3ec]
               1 com.apple.filesystems.smbfs (1.4.6) + 49907 [0x5b3b82f3]
         11 _VNOP_REMOVE + 176 [0x1f5c8c]
           11 _VNOP_SETATTR + 1421 [0x1f588e]
             11 _namei + 1237 [0x1d745e]
               11 _lookup + 661 [0x1d66c7]
                 11 _VNOP_LOOKUP + 110 [0x1f4da4]
                   11 com.apple.filesystems.smbfs (1.4.6) + 77029 [0x5b3bece5]
                     11 com.apple.filesystems.smbfs (1.4.6) + 49215 [0x5b3b803f]
                       11 com.apple.filesystems.smbfs (1.4.6) + 46324 [0x5b3b74f4]
                         11 com.apple.filesystems.smbfs (1.4.6) + 128278 [0x5b3cb516]
                           11 com.apple.filesystems.smbfs (1.4.6) + 124651 [0x5b3ca6eb]
                             11 com.apple.filesystems.smbfs (1.4.6) + 122984 [0x5b3ca068]
                               11 _msleep + 157 [0x3863e8]
                                 11 _uiomove + 608 [0x38600a]
                                   11 _lck_mtx_sleep_deadline + 104 [0x130e26]
                                     11 _thread_block + 33 [0x136f20]
                                       9 _thread_continue + 1180 [0x136cb3]
                                       2 _thread_block_reason + 135 [0x136e7c]
                                         2 _thread_setrun + 3597 [0x136217]
                                           2 _machine_idle + 271 [0x1ac3ec]
     11 _symlink + 222 [0x1e4ee7]
       11 _namei + 1237 [0x1d745e]
         11 _lookup + 661 [0x1d66c7]
           11 _VNOP_LOOKUP + 110 [0x1f4da4]
             10 com.apple.filesystems.smbfs (1.4.6) + 77029 [0x5b3bece5]
               10 com.apple.filesystems.smbfs (1.4.6) + 49215 [0x5b3b803f]
                 10 com.apple.filesystems.smbfs (1.4.6) + 46324 [0x5b3b74f4]
                   10 com.apple.filesystems.smbfs (1.4.6) + 128278 [0x5b3cb516]
                     10 com.apple.filesystems.smbfs (1.4.6) + 124651 [0x5b3ca6eb]
                       10 com.apple.filesystems.smbfs (1.4.6) + 122984 [0x5b3ca068]
                         10 _msleep + 157 [0x3863e8]
                           10 _uiomove + 608 [0x38600a]
                             10 _lck_mtx_sleep_deadline + 104 [0x130e26]
                               10 _thread_block + 33 [0x136f20]
                                 10 _thread_continue + 1180 [0x136cb3]
             1 com.apple.filesystems.smbfs (1.4.6) + 77487 [0x5b3beeaf]
               1 com.apple.filesystems.smbfs (1.4.6) + 12335 [0x5b3af02f]
                 1 com.apple.filesystems.smbfs (1.4.6) + 7036 [0x5b3adb7c]
                   1 _kalloc + 25 [0x12fde1]
     10 _readlink + 381 [0x1e6aa0]
       10 _VNOP_READLINK + 104 [0x1f5ff1]
         10 com.apple.filesystems.smbfs (1.4.6) + 72823 [0x5b3bdc77]
           10 com.apple.filesystems.smbfs (1.4.6) + 21272 [0x5b3b1318]
             10 com.apple.filesystems.smbfs (1.4.6) + 128278 [0x5b3cb516]
               10 com.apple.filesystems.smbfs (1.4.6) + 124651 [0x5b3ca6eb]
                 10 com.apple.filesystems.smbfs (1.4.6) + 122984 [0x5b3ca068]
                   10 _msleep + 157 [0x3863e8]
                     10 _uiomove + 608 [0x38600a]
                       10 _lck_mtx_sleep_deadline + 104 [0x130e26]
                         10 _thread_block + 33 [0x136f20]
                           8 _thread_continue + 1180 [0x136cb3]
                           2 _thread_block_reason + 135 [0x136e7c]
                             2 _thread_setrun + 3597 [0x136217]
                               2 _machine_idle + 271 [0x1ac3ec]


I have only tested this with SMB shares.

-- Pete


On Oct 20, 2009, at 9:31 PM, David Reitter wrote:

Pete,

that's a pretty good analysis so far.

Yes, the dump would help.  You can also run Aquamacs under gdb and interrupt the process when the hang occurs.  "bt" gives you a backtrace.

I would run it with "run -Q" from gdb.

Also, does this not occur with 1.9?

Have you tested it only on SMB shares, or also on normal AFP ones?

- David

On Oct 20, 2009, at 4:59 PM, siemsen@... wrote:

I still have this problem, which I previously mistakenly referred to as a problem with auto-save files.  It's really a problem with lock files.  It happens in version "2.0preview2" and "2.0dev".

The problem is: when editing network-mounted files, Aquamacs doesn't process lock files correctly.  If I open an existing network-mounted file named abc.txt, Aquamacs creates a lock file in the same directory as the source file, on the remote system.  The lock file is a symbolic link named ".#abc.txt".  An ls command shows

  .#abc.txt -> siemsen@...

As described in the "File Locks" section of the "GNU Emacs Lisp Reference Manual", the link points back to the Aquamacs process on my Mac, which is named galway.scd.ucar.edu.  The process is running as user siemsen, and the PID is 12194.

So far, so good.  The problem is that when I finish editing the file, the lock file isn't deleted.  When I try to edit the file later, Aquamacs lets me open file, but hangs the instant I try to modify it.  Aquamacs locks up with the spinning wheel of death, and I have to Force Quit.  If I then go to the remote system and manually delete the lock file, Aquamacs can edit the file with no problems.

I don't see lock files created when I edit files on my local system - only network-mounted files.  The manual says I should be able to test whether a file is locked with file-locked-p, but that function doesn't seem to be implemented in Aquamacs.  Could it be that Aquamacs doesn't implement file locks, but something different happens with network-mounted files?

FWIW, I found the code for filelock.c, which implements file-locked-p and unlock-buffer.  I see that unlock-buffer calls the C function named unlock_file, which uses a call to unlink to delete lock files.  Perhaps unlock_file should check the status code returned by unlink.

This is easily repeatable, and quite annoying.  I'd be happy to supply the dump from Force Quit if it would help.

- Pete

_______________________________________________
Aquamacs-devel mailing list
Aquamacs-devel@...
http://lists.aquamacs.org/mailman/listinfo.cgi/aquamacs-devel

[davidswelt]

Hey Pete,
it sounds to me like there's a problem with the file system (since the  
rm command doesn't work), and the hang just follows from that.
Of course, unlink() might not be guaranteed to work properly.  I don't  
see any loops in lock_file() (filelock.c), but I wouldn't be surprised  
if something's waiting for the file to go away (and unlink()ing  
repeatedly).

- David

On Oct 25, 2009, at 1:47 PM, Pete Siemsen wrote:

> David,
>
> With gdb on "2.0preview2", here's the backtrace:
>
> (gdb) bt
> #0  0x94d5da76 in unlink ()
> #1  0x000f864f in current_lock_owner ()
> #2  0x000f86e7 in lock_if_free ()
> #3  0x000f8926 in lock_file ()
> #4  0x000fe2ad in prepare_to_modify_buffer ()
> #5  0x000fd6be in del_range_1 ()
> #6  0x000fd625 in del_range ()
> #7  0x00116dfa in Fdelete_char ()
> #8  0x00169c15 in Ffuncall ()
> #9  0x00164532 in Fcall_interactively ()
> #10 0x00169c48 in Ffuncall ()
> #11 0x00169704 in call3 ()
> #12 0x000daa38 in Fcommand_execute ()
> #13 0x000c9e31 in command_loop_1 ()
> #14 0x00167030 in internal_condition_case ()
> #15 0x000c7ca2 in command_loop_2 ()
> #16 0x001669c1 in internal_catch ()
> #17 0x000c7c2b in command_loop ()
> #18 0x000c71ff in recursive_edit_1 ()
> #19 0x000c7408 in Frecursive_edit ()
> #20 0x000c5710 in main ()
> (gdb)
>
>
> Yes, it also occurs with 1.9.  Using 1.9, here's the top part of a  
> dump after a Force Quit:
>
> Date/Time:      2009-10-21 08:49:09 -0600
> OS Version:     10.5.8 (Build 9L30)
> Architecture:   i386
> Report Version: 4
>
> Command:        Aquamacs
> Path:           /Applications/Aquamacs Emacs.app/Contents/MacOS/
> Aquamacs Emacs
> Version:        Aquamacs 1.9, GNU Emacs 22 (1.9)
> Parent:         launchd [125]
>
> PID:            4883
> Event:          hang
> Time:           8.02s
> Steps:          48
>
>
> Process:        Aquamacs Emacs [4883]
> Path:           /Applications/Aquamacs Emacs.app/Contents/MacOS/
> Aquamacs Emacs
>
>  ADDRESS         BINARY
>  00001000        /Applications/Aquamacs Emacs.app/Contents/MacOS/
> Aquamacs Emacs
>  01781000        /System/Library/PrivateFrameworks/
> URLMount.framework/URLMount
>  020eb000        /System/Library/CoreServices/RawCamera.bundle/
> Contents/MacOS/RawCamera
>  02464000        /System/Library/Filesystems/URLMount/smb.URLMounter/
> Contents/MacOS/smb
>
>  Thread id:      8f16998
>  User stack:
>    48 _prepare_to_modify_buffer + 383 (in Aquamacs Emacs) [0xc525a]
>      27 ___unlink + 10 (in libSystem.B.dylib) [0x94d5da76]
>      11 ___symlink + 10 (in libSystem.B.dylib) [0x94d9879e]
>      10 ___readlink + 10 (in libSystem.B.dylib) [0x94d55a0e]
>  Kernel stack:
>    48 _unix_syscall + 572 [0x3e3a7f]
>      27 _unlink + 113 [0x1e55b1]
>        27 _undelete + 665 [0x1e5403]
>          16 _VNOP_REMOVE + 119 [0x1f5c53]
>            16 com.apple.filesystems.smbfs (1.4.6) + 69064 [0x5b3bcdc8]
>              16 com.apple.filesystems.smbfs (1.4.6) + 68698  
> [0x5b3bcc5a]
>                15 com.apple.filesystems.smbfs (1.4.6) + 34555  
> [0x5b3b46fb]
>                  15 com.apple.filesystems.smbfs (1.4.6) + 125137  
> [0x5b3ca8d1]
>                    15 com.apple.filesystems.smbfs (1.4.6) + 124651  
> [0x5b3ca6eb]
>                      15 com.apple.filesystems.smbfs (1.4.6) + 122984  
> [0x5b3ca068]
>                       _______________________________________________
> Aquamacs-devel mailing list
> Aquamacs-devel@...
> http://lists.aquamacs.org/mailman/listinfo.cgi/aquamacs-devel

_______________________________________________
Aquamacs-devel mailing list
Aquamacs-devel@...
http://lists.aquamacs.org/mailman/listinfo.cgi/aquamacs-devel

[Pete Siemsen]

David,

Yes, it's a problem with Samba-mounted filesystems.  I found the  
following reference to the problem:

    http://osdir.com/ml/bug-gnu-emacs-gnu/2009-04/msg00200.html

The suggested workaround is to set "unix extensions = no" in the  
configuration file on the Samba server.  I did that and the problem is  
"solved" - Aquamacs no longer creates lock files at all.  It probably  
tries and fails, silently.  I don't have the benefit of lock files,  
but Aquamacs doesn't hang.  It's a reasonable workaround.

-- Pete


On Oct 27, 2009, at 5:58 PM, David Reitter wrote:

> Hey Pete,
> It sounds to me like there's a problem with the file system (since  
> the rm command doesn't work), and the hang just follows from that.  
> Of course, unlink() might not be guaranteed to work properly.  I  
> don't see any loops in lock_file() (filelock.c), but I wouldn't be  
> surprised if something's waiting for the file to go away (and  
> unlink()ing repeatedly).
>
> - David

_______________________________________________
Aquamacs-devel mailing list
Aquamacs-devel@...
http://lists.aquamacs.org/mailman/listinfo.cgi/aquamacs-devel

[Sidney Markowitz]

siemsen@... wrote, On 10/11/09 6:04 PM:
> David,
>
> Yes, it's a problem with Samba-mounted filesystems.  I found the  
> following reference to the problem:
>
>     http://osdir.com/ml/bug-gnu-emacs-gnu/2009-04/msg00200.html
>
> The suggested workaround is to set "unix extensions = no" in the  
> configuration file on the Samba server.

I did some digging about it and found that it is a problem with the way
Leopard's smb client handles symlinks on Samba shares with unix
extensions enabled. I haven't been able to tell from the discussions
whether the behavior is supposed to be a bug or a feature. Nobody I
found has a workaround for the Mac side, only disabling unix extensions
on the server side, which then has its own negative side effects.

Is there a reason why Emacs could not create an actual 0-length file
instead of using a symlink for the lock?

For some representative discussions see

http://www.rc.au.net/blog/2007/11/19/fixing-the-smb-symlink-problem-with-mac-os-x-105-leopard/

http://ubuntuforums.org/showthread.php?t=1077823

http://bugs.contribs.org/show_bug.cgi?id=4164

or just Google for it

http://www.google.com/search?q=samba+unix+extensions+symlink+mac+os

_______________________________________________
Aquamacs-devel mailing list
Aquamacs-devel@...
http://lists.aquamacs.org/mailman/listinfo.cgi/aquamacs-devel

[davidswelt]

Pete,
well done.  Could you add this to the knowledge base/FAQ in the Wiki?
- David

On Nov 10, 2009, at 12:04 AM, siemsen@... wrote:

> David,
>
> Yes, it's a problem with Samba-mounted filesystems.  I found the  
> following reference to the problem:
>
>   http://osdir.com/ml/bug-gnu-emacs-gnu/2009-04/msg00200.html
>
> The suggested workaround is to set "unix extensions = no" in the  
> configuration file on the Samba server.  I did that and the problem  
> is "solved" - Aquamacs no longer creates lock files at all.  It  
> probably tries and fails, silently.  I don't have the benefit of  
> lock files, but Aquamacs doesn't hang.  It's a reasonable workaround.
>
> -- Pete
>
>
> On Oct 27, 2009, at 5:58 PM, David Reitter wrote:
>
>> Hey Pete,
>> It sounds to me like there's a problem with the file system (since  
>> the rm command doesn't work), and the hang just follows from that.  
>> Of course, unlink() might not be guaranteed to work properly.  I  
>> don't see any loops in lock_file() (filelock.c), but I wouldn't be  
>> surprised if something's waiting for the file to go away (and unlink
>> ()ing repeatedly).
>>
>> - David
>
> _______________________________________________
> Aquamacs-devel mailing list
> Aquamacs-devel@...
> http://lists.aquamacs.org/mailman/listinfo.cgi/aquamacs-devel

_______________________________________________
Aquamacs-devel mailing list
Aquamacs-devel@...
http://lists.aquamacs.org/mailman/listinfo.cgi/aquamacs-devel

[Pete Siemsen]

Sidney,

Here's why Emacs uses symbolic links instead of simple 0-length  
regular files.  From the comments in filelock.c, which contains the  
file locking code for Emacs/Aquamacs:

> We use symlinks instead of normal files because (1) they can be  
> stored more efficiently on the filesystem, since the kernel knows  
> they will be small, and (2) all the info about the lock can be read  
> in a single system call (readlink).  Although we could use regular  
> files to be useful on old systems lacking symlinks, nowadays  
> virtually all such systems are probably single-user anyway, so it  
> didn't seem worth the complication.
>
> Similarly, we don't worry about a possible 14-character limit on  
> file names, because those are all the same systems that don't have  
> symlinks.
>
> This is compatible with the locking scheme used by Interleaf (which  
> has contributed this implementation for Emacs), and was designed by  
> Ethan Jacobson, Kimbo Mundy, and others.

I'm the only user of Aquamacs at my site, so I don't have a tremendous  
need for lock files to work.  Turning off Unix extensions in the  
server has fixed the problem for me.  Still, it seems that file  
locking could use some improvements.  Suppose there were a new  
variable named file-lock-algorithm, which can have one of 3 settings:

1. Use the current method, with symlinks.  This would be the default.
2. No file locking.
3. Use regular 0-length files, not symlinks.

Before I actually request this of the Emacs gods, what do you think?

Cheers,

-- Pete


On Nov 10, 2009, at 4:08 AM, Sidney Markowitz wrote:

> siemsen@... wrote, On 10/11/09 6:04 PM:
>> David,
>> Yes, it's a problem with Samba-mounted filesystems.  I found the  
>> following reference to the problem:
>>    http://osdir.com/ml/bug-gnu-emacs-gnu/2009-04/msg00200.html
>> The suggested workaround is to set "unix extensions = no" in the  
>> configuration file on the Samba server.
>
> I did some digging about it and found that it is a problem with the  
> way Leopard's smb client handles symlinks on Samba shares with unix  
> extensions enabled. I haven't been able to tell from the discussions  
> whether the behavior is supposed to be a bug or a feature. Nobody I  
> found has a workaround for the Mac side, only disabling unix  
> extensions on the server side, which then has its own negative side  
> effects.
>
> Is there a reason why Emacs could not create an actual 0-length file  
> instead of using a symlink for the lock?
>
> For some representative discussions see
>
> http://www.rc.au.net/blog/2007/11/19/fixing-the-smb-symlink-problem-with-mac-os-x-105-leopard/
>
> http://ubuntuforums.org/showthread.php?t=1077823
>
> http://bugs.contribs.org/show_bug.cgi?id=4164
>
> or just Google for it
>
> http://www.google.com/search?q=samba+unix+extensions+symlink+mac+os
>

_______________________________________________
Aquamacs-devel mailing list
Aquamacs-devel@...
http://lists.aquamacs.org/mailman/listinfo.cgi/aquamacs-devel

[davidswelt]

On Nov 10, 2009, at 1:55 PM, Pete Siemsen wrote:
>  
> I'm the only user of Aquamacs at my site, so I don't have a tremendous need for lock files to work.  Turning off Unix extensions in the server has fixed the problem for me.  Still, it seems that file locking could use some improvements.  Suppose there were a new variable named file-lock-algorithm, which can have one of 3 settings:
>
> 1. Use the current method, with symlinks.  This would be the default.
> 2. No file locking.
> 3. Use regular 0-length files, not symlinks.
>
> Before I actually request this of the Emacs gods, what do you think?

You're creating a workaround in Emacs for a bug that is really in Samba as far as I understand it.  Right?
Why not work on fixing the real bug?

The file system guarantees symlinks to the application, and if Samba provides symlinks that don't work... Samba needs to be fixed...

My two cents.
_______________________________________________
Aquamacs-devel mailing list
Aquamacs-devel@...
http://lists.aquamacs.org/mailman/listinfo.cgi/aquamacs-devel

[Sidney Markowitz]

David Reitter wrote, On 12/11/09 5:05 AM:
> You're creating a workaround in Emacs for a bug that is really in
> Samba as far as I understand it.  Right? Why not work on fixing the
> real bug?

I don't fully understand what is going on from the threads at the links
that I posted and I have not yet been able to reproduce the problem on
samba ahares that I have access to, but I get the impression that the
problem is with Leopard's Samba client, not the server. Just to be
clear, Peter, are you using Leopard or Snow Leopard? The threads I have
found are all too old for me to know if the problem has been seen in
Snow Leopard.

If Linux and Unix samba clients support the samba unix extensions (which
I assume that they do) and you can create and delete symliks on samba
shares under *nix without this problem, that does point to the problem
being on the Mac side.

Peter, would you create a link that exhibits the problem (i.e., rm
doesn't delete it) and see what

   ls -l@eO symlinkname

has to say about it? I would like to see just what there is in the
permissions or access control that makes it not deletable by the owner.

If you
  chmod -N symlinkname
does that allow you to rm it?

  -- sidney

_______________________________________________
Aquamacs-devel mailing list
Aquamacs-devel@...
http://lists.aquamacs.org/mailman/listinfo.cgi/aquamacs-devel

[Pete Siemsen]

I assume that there are other environments where symbolic links don't  
work (Windows?).  When the Emacs developers chose to use symbolic  
links rather than simple files, they did so to get a miniscule  
improvement in performance and space.  They were focused on Unix.  
Simple files would work as well, and would be more portable.

It happens that I'm one of the people at my site that can modify the  
configuration of our shared Samba server, so I was able to work around  
the problem.  Had I not been able to reconfigure the Samba server, I  
would've been stuck.  The problem was disastrous - Aquamacs would hang  
completely, requiring a Force Quit, killing all open frames.  It was  
so annoying that I stopped using Aquamacs to edit files on that server.

Yes, I'm recommending a modification to Emacs to help get around a  
Samba problem, but it may help anyone who has a system that doesn't  
support symbolic links, for whatever reason.  It wouldn't be hard to  
implement.  Emacs would behave the same, but allow different behavior  
for environments where symbolic links don't work.

- Pete


On Nov 11, 2009, at 9:05 AM, David Reitter wrote:

> On Nov 10, 2009, at 1:55 PM, Pete Siemsen wrote:
>>
>> I'm the only user of Aquamacs at my site, so I don't have a  
>> tremendous need for lock files to work.  Turning off Unix  
>> extensions in the server has fixed the problem for me.  Still, it  
>> seems that file locking could use some improvements.  Suppose there  
>> were a new variable named file-lock-algorithm, which can have one  
>> of 3 settings:
>>
>> 1. Use the current method, with symlinks.  This would be the default.
>> 2. No file locking.
>> 3. Use regular 0-length files, not symlinks.
>>
>> Before I actually request this of the Emacs gods, what do you think?
>
> You're creating a workaround in Emacs for a bug that is really in  
> Samba as far as I understand it.  Right?
> Why not work on fixing the real bug?
>
> The file system guarantees symlinks to the application, and if Samba  
> provides symlinks that don't work... Samba needs to be fixed...
>
> My two cents.
> _______________________________________________
> Aquamacs-devel mailing list
> Aquamacs-devel@...
> http://lists.aquamacs.org/mailman/listinfo.cgi/aquamacs-devel

_______________________________________________
Aquamacs-devel mailing list
Aquamacs-devel@...
http://lists.aquamacs.org/mailman/listinfo.cgi/aquamacs-devel

[davidswelt]

I'd say take it to emacs-devel.

If you do want to change the way Emacs does file locking, then it should be done consistently rather than with an option, unless there are good reasons to use the old method (symlinks).  I don't know if there are any (the small space saving you point out is not a good reason).

As said before, the best way to fix it would be to fix Samba, but I realize that this may be impossible.  They should have a better idea on emacs-devel.

- D


On Nov 11, 2009, at 3:11 PM, siemsen@... wrote:

> I assume that there are other environments where symbolic links don't work (Windows?).  When the Emacs developers chose to use symbolic links rather than simple files, they did so to get a miniscule improvement in performance and space.  They were focused on Unix.  Simple files would work as well, and would be more portable.
>
> It happens that I'm one of the people at my site that can modify the configuration of our shared Samba server, so I was able to work around the problem.  Had I not been able to reconfigure the Samba server, I would've been stuck.  The problem was disastrous - Aquamacs would hang completely, requiring a Force Quit, killing all open frames.  It was so annoying that I stopped using Aquamacs to edit files on that server.
>
> Yes, I'm recommending a modification to Emacs to help get around a Samba problem, but it may help anyone who has a system that doesn't support symbolic links, for whatever reason.  It wouldn't be hard to implement.  Emacs would behave the same, but allow different behavior for environments where symbolic links don't work.
>
> - Pete
>
>
> On Nov 11, 2009, at 9:05 AM, David Reitter wrote:
>
>> On Nov 10, 2009, at 1:55 PM, Pete Siemsen wrote:
>>>
>>> I'm the only user of Aquamacs at my site, so I don't have a tremendous need for lock files to work.  Turning off Unix extensions in the server has fixed the problem for me.  Still, it seems that file locking could use some improvements.  Suppose there were a new variable named file-lock-algorithm, which can have one of 3 settings:
>>>
>>> 1. Use the current method, with symlinks.  This would be the default.
>>> 2. No file locking.
>>> 3. Use regular 0-length files, not symlinks.
>>>
>>> Before I actually request this of the Emacs gods, what do you think?
>>
>> You're creating a workaround in Emacs for a bug that is really in Samba as far as I understand it.  Right?
>> Why not work on fixing the real bug?
>>
>> The file system guarantees symlinks to the application, and if Samba provides symlinks that don't work... Samba needs to be fixed...
>>
>> My two cents.
>> _______________________________________________
>> Aquamacs-devel mailing list
>> Aquamacs-devel@...
>> http://lists.aquamacs.org/mailman/listinfo.cgi/aquamacs-devel
>
> _______________________________________________
> Aquamacs-devel mailing list
> Aquamacs-devel@...
> http://lists.aquamacs.org/mailman/listinfo.cgi/aquamacs-devel

_______________________________________________
Aquamacs-devel mailing list
Aquamacs-devel@...
http://lists.aquamacs.org/mailman/listinfo.cgi/aquamacs-devel

[Sidney Markowitz]

I did some more digging. I was able to reproduce the problem in Snow
Leopard by creating a virtual machine in VirtualBox running Ubuntu 9.10,
  installing Samba 3.4.0, setting the networking to Host mode, and
sharing a directory. When I mounted the share in Finder and went to the
directory in a Terminal command line, I found that I could create a
symbolic link to a non-existent file

   ln -s nonsense foo

and saw that the permissions were ok, the owner was listed as my Mac
account name which was different from the linux account name, and there
were no restrictive ACL entries when I did

  ls -ale@O foo


However rm foo failed with a file not found error. When I created the
file "nonsense" the rm succeeded.

I tried ln -s /tmp/nonsense foo with the same result. Creating
/tmp/nonsense on the Mac did not help, but creating /tmp/nonsense on the
server allowed the rm to work.

chown -i foo ; chown -I foo ; chow -N foo

did not allow me to rm foo when it was producing the error.

I then created another virtual machine running Ubuntu 9.10 and mounted
the share on that. It worked fine, but then I created a new user account
and deleted the old one so that UID and GID would not match on the two
virtual machines, which more closely resembles the situation with the
Mac. When I did that I could no longer write anything to the directory
because the owner was listed as being the UID and GID of the owner
account the files had on the server.

I would say that unix permissions yes just doesn't work well enough when
it is both on the server and the client, and that's true for both Mac
and linix as a totally separate issue from Aquamacs

  -- sidney

_______________________________________________
Aquamacs-devel mailing list
Aquamacs-devel@...
http://lists.aquamacs.org/mailman/listinfo.cgi/aquamacs-devel

[Sidney Markowitz]

[My lat few emails on this topic have not arrived on the mailing list]

After yet more digging, I was able to get samba shares working properly
on Ubuntu to Ubuntu. The trick was not using sudo to mount, and setting
up a mountpoint in my home directory on the client so it did not have to
be mounted using sudo. When I did that the symbolic link could be
deleted when using the Linux client.

I then used mount -t smbfs from the command lime on the Mac to make sure
I mounted with the same parameters, and it still had the problem with
not being able to rm the symlink with the error message about there
being no such file or directory. Again, creating the target file on the
server allowed the rm to not produce the error message.

However, something that I didn't notice before: When I create the file
that is the target of the ln -s, the rm no longer produces the error
message about the file not being found, but the link is not deleted even
though there is no error message.

So the problem is back to Apple's smbfs client.

  -- sidney

_______________________________________________
Aquamacs-devel mailing list
Aquamacs-devel@...
http://lists.aquamacs.org/mailman/listinfo.cgi/aquamacs-devel

[Pete Siemsen]

On Nov 11, 2009, at 12:33 PM, Sidney Markowitz wrote:

> David Reitter wrote, On 12/11/09 5:05 AM:
>> You're creating a workaround in Emacs for a bug that is really in
>> Samba as far as I understand it.  Right? Why not work on fixing the
>> real bug?
>
> I don't fully understand what is going on from the threads at the  
> links that I posted and I have not yet been able to reproduce the  
> problem on samba shares that I have access to, but I get the  
> impression that the problem is with Leopard's Samba client, not the  
> server. Just to be clear, Peter, are you using Leopard or Snow  
> Leopard? The threads I have found are all too old for me to know if  
> the problem has been seen in Snow Leopard.
>
> If Linux and Unix samba clients support the samba unix extensions  
> (which I assume that they do) and you can create and delete symliks  
> on samba shares under *nix without this problem, that does point to  
> the problem being on the Mac side.
>
> Peter, would you create a link that exhibits the problem (i.e., rm  
> doesn't delete it) and see what
>
>  ls -l@eO symlinkname
>
> has to say about it? I would like to see just what there is in the  
> permissions or access control that makes it not deletable by the  
> owner.
>
> If you
> chmod -N symlinkname
> does that allow you to rm it?
>
> -- sidney

Sidney,

I'm using Leopard on my Mac.  On the server, its Debian 5.0.3 and smbd  
3.2.5.  Since I changed added "unix extensions = no" to the smb.conf  
file on the server, Aquamacs no longer creates lock files.  If I  
manually create a symlink on the server, and then look at it with my  
Mac named galway, I see this:

galway$ ls -l@eO /Volumes/web/nets/intro/staff/siemsen/indexlink
-rwx------  1 siemsen  staff  - 2031 Oct 21 08:36 /Volumes/web/nets/
intro/staff/siemsen/indexlink
galway$ rm /Volumes/web/nets/intro/staff/siemsen/indexlink
galway$ ls -l@eO /Volumes/web/nets/intro/staff/siemsen/indexlink
-rwx------  1 siemsen  staff  - 2031 Oct 21 08:36 /Volumes/web/nets/
intro/staff/siemsen/indexlink
galway$

Notice that the "rm" command failed to delete the symlink, but it  
gives no error messages, about permissions or anything else.  It just  
silently fails.

I agree, the problem seems to be in the Mac Samba client.  It doesn't  
support "Unix Extensions" correctly, so it can't delete symlinks.  
When I turned off "unix extensions" in the Samba server, it changed  
things so the Mac Samba client can't create symlinks either.  This  
"fixed" my Aquamacs problem in a roundabout way.

-- Pete



_______________________________________________
Aquamacs-devel mailing list
Aquamacs-devel@...
http://lists.aquamacs.org/mailman/listinfo.cgi/aquamacs-devel

[davidswelt]

On Nov 11, 2009, at 3:11 PM, siemsen@... wrote:

> I assume that there are other environments where symbolic links don't work (Windows?).  When the Emacs developers chose to use symbolic links rather than simple files, they did so to get a miniscule improvement in performance and space.  They were focused on Unix.  Simple files would work as well, and would be more portable.


The changes would comprise more than a few lines of code I think.
What could be done more easily is to address the specific failure to delete the lock, allowing people to at least edit the file and ignore the lock if it is a SMB file system, or fail gracefully rather than hanging.


This excerpt from filelock.c might also be informative:


/* The strategy: to lock a file FN, create a symlink .#FN in FN's
   directory, with link data `user@...'.  This avoids a single
   mount (== failure) point for lock files.

   When the host in the lock data is the current host, we can check if
   the pid is valid with kill.

   Otherwise, we could look at a separate file that maps hostnames to
   reboot times to see if the remote pid can possibly be valid, since we
   don't want Emacs to have to communicate via pipes or sockets or
   whatever to other processes, either locally or remotely; rms says
   that's too unreliable.  Hence the separate file, which could
   theoretically be updated by daemons running separately -- but this
   whole idea is unimplemented; in practice, at least in our
   environment, it seems such stale locks arise fairly infrequently, and
   Emacs' standard methods of dealing with clashes suffice.

   We use symlinks instead of normal files because (1) they can be
   stored more efficiently on the filesystem, since the kernel knows
   they will be small, and (2) all the info about the lock can be read
   in a single system call (readlink).  Although we could use regular
   files to be useful on old systems lacking symlinks, nowadays
   virtually all such systems are probably single-user anyway, so it
   didn't seem worth the complication.

   Similarly, we don't worry about a possible 14-character limit on
   file names, because those are all the same systems that don't have
   symlinks.

   This is compatible with the locking scheme used by Interleaf (which
   has contributed this implementation for Emacs), and was designed by
   Ethan Jacobson, Kimbo Mundy, and others.

   --karl@.../karl@....  */

_______________________________________________
Aquamacs-devel mailing list
Aquamacs-devel@...
http://lists.aquamacs.org/mailman/listinfo.cgi/aquamacs-devel