remove file access denied(remove broke)
bauss
jj_1337 at live.dk
Fri Sep 14 11:41:31 UTC 2018
On Friday, 14 September 2018 at 08:32:48 UTC, Josphe Brigmo wrote:
> On Friday, 14 September 2018 at 04:48:09 UTC, Norm wrote:
>> On Thursday, 13 September 2018 at 23:25:24 UTC, Josphe Brigmo
>> wrote:
>>> I am trying to remove a file
>>>
>>> remove(filename);
>>>
>>> and I get an access denied!
>>>
>>> I can remove it from explorer just fine.
>>>
>>> I am able to remove other files but there should be no reason
>>> why the file can't be removed in this case.
>>>
>>> All I am doing to mess with the file is reading it's contents
>>> right before to do a file compare(I am removing the file if
>>> it is a duplicate).
>>>
>>> Does read() lock the file at all? (maybe the lock is
>>> persisting just long enough to make the remove fail?
>>>
>>> Since I can delete the file outside the program and since the
>>> filename is valid(I copied and pasted it to remove it to
>>> check), This seems like a D problem.
>>
>> Do you have the file open when you call remove? If so close
>> the file handle before the remove call. If you can post a
>> stripped down version of your code it would also help.
>>
>> bye,
>> Norm
>
> No, I use read, there is no file handles. Pointless to post
> code because it won't offer much. Also, I have security
> privileges.
>
> I simply read the file to compare it's contents then I try to
> remove the file if it had the same contents and it says it is
> invalid. I also, of course, check that it exist and is a file.
>
> This is all I'm doing that is related to file reading and I
> cannot remove the file(but can read it and such).
>
> So, I'm really wondering if read locks the file but doesn't
> release it in time.
>
> Using lockHunder shows the file isn't locked but the directory
> is(Probably because I'm iterating through it.
>
> Seems it is an error with remove, using executeShell works fine:
>
> auto ls = executeShell(`del /F /Q "`~fn~`"`);
>
> which does not give an error but remove(fn) does.
>
> Seems remove is broke.
It's not necessarily a permission issue, but might be an issue
with the files attributes.
If you're on Windows try this:
setAttributes(filename, 0x80);
0x80 means normal.
You can always try to retrieve the attributes using
getAttributes(filename) and see what you retrieve and if there
are anything odd going on.
D really needs an enum of the file attributes on windows and the
examples are poor, because they only show examples related to
Posix lol.
More information about the Digitalmars-d-learn
mailing list