delete will assure file is deleted?

[ajikoe]

Hello,

If I use os.remove(fileName), does it always assure that the code will
move to the next code only if the fileName is deleted completely?

Pujo

 

[Mike Meyer]

Hello,

If I use os.remove(fileName), does it always assure that the code will
move to the next code only if the fileName is deleted completely?

Hmm. The documdentation doesn't say. A quick test on FreeBSD shows
that if you don't have permission to remove the file, an exception is
raised. A second test shows that you get a the same exception if the
file doesn't exist.

Things in os tend to be tied tightly to the underlying platform. You
might want to test on your platform.

<mike

 

[ajikoe]

Hello Mike,
I have to know this topic otherwise my program has to check whether the
file / files are already deleted and this is a little bit messy.

Pujo

 

[Maciej Dziardziel]

Hello,

If I use os.remove(fileName), does it always assure that the code will
move to the next code only if the fileName is deleted completely?

Yes, it will be deleted, but not necessary completly. Deleting isn't equal
to erasing file's content, so it might be possible to recover deleted file,
plus on some systems deleted files are kept for those processes (and only
for them), who are still using them, and disappear when everyone close
them.

 

[Dennis Lee Bieber]

Hello Mike,
I have to know this topic otherwise my program has to check whether the
file / files are already deleted and this is a little bit messy.

Ah, but this requirement is different from the one you
originally asked.

In either event, the best solution is probably to wrap the call
with a try block...

try:
os.remove(fileName)
except <need to determine what errors can be raised>:
# do whatever you need for the error
except <other error>:
# do whatever this error needs...

If the error is that the file didn't exist to be deleted, you
can probably use a "pass" as the except processing.

--

 

[rbt]

Hello Mike,
I have to know this topic otherwise my program has to check whether the
file / files are already deleted and this is a little bit messy.

Pujo

How about checking with isfile() before and after?

 

[Jeremy Bowers]

Hello Mike,
I have to know this topic otherwise my program has to check whether the
file / files are already deleted and this is a little bit messy.

I would be fairly confident in asserting that assuming the file is there,
you have permissions, etc., basically that the call succeeds, that the
file will be gone.

os.remove, as the module name implies, tells the OS to do something. I
would consider an OS that returned from a "remove" call, but still let you
access that file, highly broken.

You may be concerned that the OS may not write the fact that the file is
deleted to the disk right away. This is very, very possible; OSs have been
doing that for a while. If, for some reason, this is a major concern that
the system might suddenly lose power and the file may not be truly
deleted, you will need to either shut off this feature (it is called
"write-behind caching", and shutting it off, or indeed even having the
feature at all, is OS-dependent), or get a UPS so that the machine has
time to shut down gracefully.

HOWEVER... the only time this is a problem is if you are truly concerned
about the power spontaneously shutting off. The kernel of your operating
system, if indeed it does write-behind caching at all, will make it look
to all programs on the system (not just your own) that the file is
deleted; and thus, in every sense that matters barring spectacular
power failure, it is.

So I say, ever if you've heard of write-behind caching and you are perhaps
worried about it, you do not need to be; it is intended to be fully
transparent to you, and indeed, short of directly asking the OS whether
the feature is on, there should be no practical way of figuring out
whether it is on at all. All it means is significantly better performance
to you programs if they do things like delete a lot of files at once; you
don't need to worry that they might "still be there" even after the
command is done.

This reply somewhat longer than needed for the purposes of education

 

[andreas]

I would be fairly confident in asserting that assuming the file is there,
you have permissions, etc., basically that the call succeeds, that the
file will be gone.

Not exactly. The system call is called remove not by accident. It's not
called delete. So for example if you have a file with multiple names (so called
hard links) the file will not be gone after os.remove('file')

os.remove, as the module name implies, tells the OS to do something. I
would consider an OS that returned from a "remove" call, but still let you
access that file, highly broken.

Well, it has been the normal semantics with Unix for decades. Actually it's
the normal way to create temporary files that will be cleanuped when the program
exits:
f = open("temp")
os.remove("temp")
# now use f

f.close() # frees the temporary file
sys.exit(0) # exit is an implicit close too.

Andreas

 

[Jeremy Bowers]

Not exactly. The system call is called remove not by accident. It's not
called delete. So for example if you have a file with multiple names (so called
hard links) the file will not be gone after os.remove('file')

This gets into another distinction that I didn't want to get into, given
that my message was heavy enough as it is.

But I would say, that even if "file_a" and "file_b" are both (hard) linked
to the same file, and I "remove" "file_a", I am perfectly justified in
saying that "file_a" is gone, deleted, removed, what have you. The file,
the thing we called "file_a", is no longer accessible. That some operating
systems separate "file" from "contents" and thus that I can get at the
contents in some other way doesn't really make that statement untrue;
"file_a" is still gone. "file deleted" hasn't meant "file contents
eliminated from the disk entirely", well, as far as I know, *ever*;
certainly there were undelete operations in DOS, and that's as far back as
I can attest to personally, but I know that "undelete"s could be done
before then, too. In fact one must search in computing for anything to
ever truly be *eliminated*; in more than just file systems, we
de-allocate, re-allocate for something else, and just overwrite. That's a
pervasive pattern.

 

[Mike Meyer]

On Tue, 26 Apr 2005 03:40:16 -0700, (e-mail address removed) wrote:
os.remove, as the module name implies, tells the OS to do something. I
would consider an OS that returned from a "remove" call, but still let you
access that file, highly broken.

Um - not if you have permission to read the file, but don't have
permission to remove it. Whatever the "remove" call does in this case,
you *better* have access to it after the fact. The "remove" call on
Unix (uka "unlink") returns even if it can't remove the file: it
returns 0 if it succeeds, and -1 if it doesn't.

os.remove is a little brighter than that. It will throw an OSError
exception if it can't remove the file.

<mike

 

[Mike Meyer]

Ah, but this requirement is different from the one you
originally asked.

In either event, the best solution is probably to wrap the call
with a try block...

try:
os.remove(fileName)
except <need to determine what errors can be raised>:
# do whatever you need for the error
except <other error>:
# do whatever this error needs...

If the error is that the file didn't exist to be deleted, you
can probably use a "pass" as the except processing.

This is just a little bit tricky. os.remove (on FreeBSD 5-STABLE,
anyway) throws an OSError exception if it doesn't have permission to
remove the file, *or* if the file doesn't exist. You have to examine
the exception for it's value, which is the result of a strerror
call. I believe that the result of strerror is platform dependent.

<mike

 

[Jeremy Bowers]

Um - not if you have permission to read the file, but don't have
permission to remove it.

You snipped:

First paragraph.

 

[Christos TZOTZIOY Georgiou]

This is just a little bit tricky. os.remove (on FreeBSD 5-STABLE,
anyway) throws an OSError exception if it doesn't have permission to
remove the file, *or* if the file doesn't exist. You have to examine
the exception for it's value, which is the result of a strerror
call. I believe that the result of strerror is platform dependent.

Although I don't have experience with FreeBSD, so far checking the
exception's errno args does the job. Example:

import errno

try:
...
except OSError, exc:
if exc.errno == errno.ENOENT: # file inexistant
...
elif exc.errno == errno.EPERM: # no permissions
...
else:
raise

 

[Fredrik Lundh]

Although I don't have experience with FreeBSD, so far checking the
exception's errno args does the job.

if that doesn't work on FreeBSD, FreeBSD is not a proper Unix.

import errno

try:
...
except OSError, exc:
if exc.errno == errno.ENOENT: # file inexistant
...
elif exc.errno == errno.EPERM: # no permissions
...

make that

elif exc.errno in (errno.EACCES, errno.EPERM): # no permissions

</F>

 

[Christos TZOTZIOY Georgiou]

make that

elif exc.errno in (errno.EACCES, errno.EPERM): # no permissions

Yep, you're right (you wouldn't be a bot otherwise, right?-)

BTW I remember a post last summer about subclassing OSError (found it:
http://groups.google.com.gr/[email protected] --not
exactly what I remembered, but close.)

I think throwing subclasses of OSError based on errno would make life
easier --always assuming that Python requires POSIX conformance on all
platforms. I will give it a try RSN...