Mail Archives: cygwin/2001/01/02/12:12:19
I just noticed some strange behavior while using rm that i suspect is the
fault of Windows and not of cygwin, but i thought i'd float it by here to
make sure.
In bash, if you're tailing a file called, say, "loop-log", and then while
tailing it do "rm loop-log", rm does not complain that it wasn't able to
remove the file, and in fact sets the exit status to "success". But
strangeness ensues afterwards.
So here's the file before doing the rm:
BEAST$ ls -al loop-log
-rw-r--r-- 1 curlbot Administ 16 Jan 2 11:53 loop-log
BEAST$ cat loop-log
blah blah
Here's the rm (with another bash process doing the tail):
BEAST$ rm loop-log
BEAST$
No error message whatsoever. And yet here's the ls after doing the rm:
BEAST$ ls -al loop-log
-r-xr-xr-x 1 curlbot Administ 16 Jan 2 11:54 loop-log
Still there? Well, the namespace is still being taken. But now the file is
inaccessible:
BEAST$ cat loop-log
cat: loop-log: Permission denied
If i then kill my tail, the file completely disappears and the namespace
frees up. But until my tail process exits, i can't re-use the name
"loop-log" in that directory.
Is there a way to either a) get an errorlevel returned from rm if the file
isn't utterly removed (i'm guessing not, since it does believe the file is
deleted), b) delete the file in its entirety (i'm guessing not, since it's
probably Windows that's marking the file as deleted but not removing it from
the namespace), c) do something else? I'm hoping to avoid having to mv the
file and reap it later, but i suspect i'm hampered by Windows limitations.
Maybe detect somehow if the file is open, and delete it only if it's not?
John
--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple
- Raw text -