Regarding issue #21855
http://bugs.freepascal.org/view.php?id=21855

I am planning to reject the patch but I would like to have other opinions, too.

Juha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120429/3b4d1d9e/attachment.html>

Actually, I'd like to have the possibility to delete an entire directory with read only files without having to recursively remove the read only attribute first.... just as long as it doesn't do so by default.

Can e.g. be handy for backup programs removing old backup trees...

Oh, and thanks for asking the list, Juha!

My 2 cents,
Reinier

On Sun, Apr 29, 2012 at 2:39 PM, Reinier Olislagers <

I realize it would be useful sometimes.
However on *nix systems you can't change a file's read-only status if you are not the file's owner.
It may cause more problems than it solves them.
Can it be solved in a clever way, I don't know.

Zeljan's opinion is to reject the feature. I haven't heard other opinions yet.

Juha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120429/a2df4623/attachment.html>

Ok, but both on Windows and *nix, you can also have e.g. permissions problems that prevent you from deleting a file.

If those permissions problems are handled the same way as problems resetting read-only, shouldn't that be fine then?

Juha Manninen wrote

However on *nix systems you can't change a file's read-only status if you are not the file's owner.

Ok, that is not exactly true. It also depends on the file's settings for its "Group" and "Others".
Anyway, there is a chance the rights cannot be changed, but then the file cannot be deleted either.

If someone can test a solution that works well on any platform, it could be applied.
I should be doing other things already...

Juha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120429/e4e9f8fa/attachment.html>

On 4/29/12, Juha Manninen wrote:

Removing files in windows can fail also.
The flag RemoveReadOnlyFiles actually means try to also remove read-only files (just like DeleteDirectory actually tries to delete a directory).
As long as the function returns False if removing of a file/dir fails it should be OK.

I would change the declaration to:

function DeleteDirectory(const DirectoryName: string;
     OnlyChilds: boolean; const RemoveReadOnlyFiles: Boolean = False): boolean;

But that is possibly just a matter of taste.

One might also consider retuning the actual filename/foldername that could not be removed if things fail, so feedback to the user can be given.

Bart

If the suggestion is adopted it needs to be

function DeleteDirectory(const DirectoryName: string;
        OnlyChildren: boolean; ...

I'm in favor of patch with current definition (no default parameters as suggested by Bart) and with following ammendment:

     if RemoveReadOnlyFiles and ((FileInfo.Attr and faReadOnly)>0) then
       if FileSetAttrUTF8(CurFilename, FileInfo.Attr-faReadOnly)  0 then
         exit;

Instead of

     if RemoveReadOnlyFiles and ((FileInfo.Attr and faReadOnly)>0) then
       FileSetAttrUTF8(CurFilename, FileInfo.Attr-faReadOnly);

This way the function exits as soon as something goes wrong. No need iterating in directories when the attribute of the directory itself can't be changed.

Ludo

How to find out what went wrong?
Maybe add parameter 'ExceptionOnError:boolean=false' and if true then raise an exception with the file name.

Mattias

Good idea. I just kept it along the lines of the existing DeleteDirectory that just failed without raising a exception.

Ludo

I would change the declaration to: function DeleteDirectory(const DirectoryName: string; OnlyChilds: boolean; const RemoveReadOnlyFiles: Boolean =

False): boolean;

Yes, I think this needs to be changed/added
.
And what about system-hidden files?
Are they already deleted by DeleteDirectory?

In general, there was a reason for having read-only attributes in the past but meanwhile it is of not much use anymore because many programs delete such files anyway (as this thread shows ;-)).

One might also consider retuning the actual filename/foldername that could not be removed if things fail, so feedback to the user can be given.

This would only make sense if a programmer wants to present the file name to a user. But if the only reason is to know which file attributes have to be
changed and let the program try to delete them again, then the programmer should be saved to do such crude cycles and a flag should tell the routine to
delete in all cases (read-only or not).

The point of my remark was to be able to give feedback to the end user, if removing failed (e.g. because of file-access rights).

"Unable to remove file:'/path/to/somefile'"

This could be done by an out parameter, or indeed by raising an exception with the appropriate file/folder-name as suggested above.

Bart

And what about system-hidden files? Are they already deleted by DeleteDirectory?

Do we really need to deleting "hidden-file" as explicitly ? I'm afraid it would be the worst things, since might the user (not the programmer) didn't know, this is the part of system or not.

Well, actually, By the result is enough since, the user might only want to know, is process completed or not.
If failed, they can be check manually which file failed to be deleted.

Regards,
Takeda.