erase dialog: why are all files listed as protected files?

[Gilbert Ritschard]

I am running WinEdt 9 and realized that the Erase dialog does no longer erase any file, all files being listed as "protected files". None of the listed files is marked as read-only in the Windows explorer and I can delete them from there!

Can anyone explain what is happening and how I could change that?

Gilbert

[WinEdt Team]

Gilbert,

Post by Gilbert Ritschard
I am running WinEdt 9 and realized that the Erase dialog does no
longer erase any file, all files being listed as “protected files”.
None of the listed files is marked as read-only in the Windows
explorer and I can delete them from there!
Can anyone explain what is happening and how I could change that?

I could not reproduce this. Of course, in explorer you can delete
files even if their attribute is set to readonly...

The only way I was able to reproduce this was to set file (or
folder) attributes to readonly or hidden. Such files are not
deleted by design.

Furthermore, nothing has changed in this functionality in many
years (certainly not since WinEdt 7.0) and I am puzzled why would
WinEdt 9 act any differently than older versions (if this is what
you are suggesting???). Or did old versions (6-8) do the same (in
this particular folder)? Are you sure (this is important)?

Perhaps your files have some other attribute (such as temporary or
virtual or something else) that cannot be observed in explorer and
WinEdt does not take it into account. If so I would have to know
what number does Windows API function GetFileAttributes(FileName)
returns for these files. If you can make a test let me know the
return value (any Windows compiler can be used for the test -- it
does not have to be Delphi). Then I will know exactly what is going
on and I may be able to fix it (if it needs to be fixed)...

Best regards,

alex

[Gilbert Ritschard]

Dear Alex,

You are right. I checked with WinEdt 8, and the same occurs.

Experimenting a little bit, I observed that as long as .bak, .aux, .log, .synctex, etc. files are time stamped with the current month everything works smooth. When older they are listed as ‘protected’ and their count appears between parentheses on the ‘summary’ tab of the Erase Output File dialog. I did not realize that earlier.

I indeed checked that older files are not marked as read-only, and they are not!

Sorry to bother you with that.

Gilbert



From: WinEdt Team [mailto:***@winedt.com]
Sent: Wednesday, September 10, 2014 19:05
To: winedt+***@wsg.net<mailto:winedt+***@wsg.net>
Subject: Re: [WinEdt] erase dialog: why are all files listed as protected files?

Gilbert,

Post by Gilbert Ritschard
I am running WinEdt 9 and realized that the Erase dialog does no
longer erase any file, all files being listed as “protected files”.
None of the listed files is marked as read-only in the Windows
explorer and I can delete them from there!
Can anyone explain what is happening and how I could change that?

I could not reproduce this. Of course, in explorer you can delete
files even if their attribute is set to readonly...

The only way I was able to reproduce this was to set file (or
folder) attributes to readonly or hidden. Such files are not
deleted by design.

Furthermore, nothing has changed in this functionality in many
years (certainly not since WinEdt 7.0) and I am puzzled why would
WinEdt 9 act any differently than older versions (if this is what
you are suggesting???). Or did old versions (6-8) do the same (in
this particular folder)? Are you sure (this is important)?

Perhaps your files have some other attribute (such as temporary or
virtual or something else) that cannot be observed in explorer and
WinEdt does not take it into account. If so I would have to know
what number does Windows API function GetFileAttributes(FileName)
returns for these files. If you can make a test let me know the
return value (any Windows compiler can be used for the test -- it
does not have to be Delphi). Then I will know exactly what is going
on and I may be able to fix it (if it needs to be fixed)...

Best regards,

alex