This is the mail archive of the cygwin@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: infinite loop in rm -fr (revisited)


Chris January wrote:

Possible solutions:
1. rename the original file in the directory with a 'special name'.
e.g.
if deleting file1 and file1 is in use, rename to ...---file1---....
Files matching this pattern would not be returned by readdir.
2. rename the original file to a special 'holding' directory for pending
deleted files.
3. in file access routines, pretend a file does not exist if it is present
in delqueue. (e.g. check could be added to path_conv::check). Doesn't cope
with another file being created with the same name.

None of the above are ideal.
1 and 3 would fix some things, but it looks to me like #2 is the best,
because the file is really deleted, as far as its former directory
is concerned.  So you don't have problems with Windows locking the directory
down.

But then there is the problem of under what conditions Windows will let
you rename the file.  I ran a test, and, curiously, the following script
works, even though the "info" file is open when "mv" executes.

#!/bin/bash
trap "cd /; rm -fr /tmp/xxx.dir" 0
mkdir /tmp/xxx.dir
exec >/tmp/xxx.dir/info
mv /tmp/xxx.dir/info /tmp/info

Joe Buehler




--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]