Deleting files on a shared server

[Josh English]

This is a follow-up to some questions I posted a month or two ago. I have two programs running on various Windows XP boxes, sharing several resource files on a Windows 2003 server. It's a mapped drive on the workstations to a shared folder.

I am using a locking utility that works by creating ".lock" files in the shared folder and deleting those files when the program is done with them.

To delete the files, I am using os.unlink.

One lock file refuses to disappear, even though I have code at both application startup and shutdown (on the OnInit and OnExit methods to the wxPython Application object) that hunts down .lock files and deletes them.

Is there a better command than os.unlink to delete a file on Windows 2003 server?

Josh

 

[Steven D'Aprano]

This is a follow-up to some questions I posted a month or two ago. I have
two programs running on various Windows XP boxes, sharing several resource
files on a Windows 2003 server. It's a mapped drive on the workstations to
a shared folder.

I am using a locking utility that works by creating ".lock" files in the
shared folder and deleting those files when the program is done with them.

To delete the files, I am using os.unlink.

How and when? If you are deleting the files using a __del__ handler in an
instance, it is quick possible that it is never being run, or not being run
when you think it is.

For file locking, you should consider using a portable solution like this
one:

http://code.activestate.com/recipes/65203-portalocker-cross-platform-posixnt-api-for-flock-s/

One lock file refuses to disappear, even though I have code at both
application startup and shutdown (on the OnInit and OnExit methods to the
wxPython Application object) that hunts down .lock files and deletes them.

Perhaps the file is open and so can't be deleted under Windows. Are you
getting an exception when you try to unlink the file? If so, what does it
say?

Is there a better command than os.unlink to delete a file on Windows 2003
server?

No. os.unlink is a wrapper around your system's unlink command -- if it
can't delete the file, you can't delete the file.

 

[Josh English]

The problem shows up when the application starts. It tries to read the file but the lock mechanism times out because the file is still around after the last time the application ran.

It's a wxPython program. The code to unlink the .lock files is run in the wxApp.OnInit method (before any code to open these resources) and in the wxApp.OnExit method. I know both of these methods are being called.

The locking mechanism I am using can be found at http://www.evanfosmark.com/2009/01/cross-platform-file-locking-support-in-python/

The clearing code is:

import os
import fnmatch
files = fnmatch.filter(os.listdir(self.Options.DataDir), "*.lock")
for f in files:
os.unlink(os.path.abspath(os.path.join(self.Options.DataDir, f)))

The Options object has a property called DataDir.

MMM...

Now that I sit down to test abso-frikkin'-lutely that this code does what I want it to do, it appears not to do this at all. The files list I build doesn't work and returns an empty list. I may have found a workaround using glob.

Now my face is red.

 

[Tim Golden]

This is a follow-up to some questions I posted a month or two ago. I
have two programs running on various Windows XP boxes, sharing
several resource files on a Windows 2003 server. It's a mapped drive
on the workstations to a shared folder.

I am using a locking utility that works by creating ".lock" files in
the shared folder and deleting those files when the program is done
with them.

To delete the files, I am using os.unlink.

One lock file refuses to disappear, even though I have code at both
application startup and shutdown (on the OnInit and OnExit methods to
the wxPython Application object) that hunts down .lock files and
deletes them.

Assuming that your code paths succeed and that the unlink actually
happens, it is possible for files to continue to exist after they
have been successfully deleted. This happens if another process
has opened them with share-delete mode; typically this will be
a virus checker or a process like the TortoiseSVN cache (or its
counterparts for other VCS). The file won't actually disappear
until the last handle on it is released.

TJG

 

[Gabriel Genellina]

On 07/10/2011 02:14, Josh English wrote:

Assuming that your code paths succeed and that the unlink actually
happens, it is possible for files to continue to exist after they
have been successfully deleted. This happens if another process
has opened them with share-delete mode; typically this will be
a virus checker or a process like the TortoiseSVN cache (or its
counterparts for other VCS). The file won't actually disappear
until the last handle on it is released.

In such cases the openfiles command [1] is very useful for detecting who
is holding the file open.

[1]
http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/openfiles.mspx