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.

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

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.

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.

On Friday, 14 September 2018 at 08:32:48 UTC, Josphe Brigmo wrote:
> 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.

´´´
void main()
{
	import std.file : exists, read, remove;
	import std.stdio : File;
	import std.uuid : randomUUID;
	import std.file : tempDir;
	import std.path : dirSeparator;

	string tFileName = tempDir ~ dirSeparator ~ randomUUID.toString;
	
	File(tFileName, "w").close;
	assert(tFileName.exists);
	assert(tFileName.read.length == 0);
	tFileName.remove;
	assert(!tFileName.exists);
}
´´´

This works for me. And what does not for you?

On Friday, 14 September 2018 at 08:32:48 UTC, Josphe Brigmo wrote:
> Seems remove is broke.

The source code for remove is DeleteFile(name), so not much room for bugs there, except maybe string conversion. What is the filename you are working on?

On Friday, 14 September 2018 at 13:28:41 UTC, Adam D. Ruppe wrote:
> On Friday, 14 September 2018 at 08:32:48 UTC, Josphe Brigmo wrote:
>> Seems remove is broke.
>
> The source code for remove is DeleteFile(name), so not much room for bugs there, except maybe string conversion. What is the filename you are working on?

It happens on a bunch. I do get errors or overlong file names but this doesn't seem to be the case.

The fact is, that simply using execute shell using the same file name works. So this is a D problem.

It happens quite often and every time I can delete the files in file explorer.

On Fri, Sep 14, 2018 at 02:36:34PM +0000, Josphe Brigmo via Digitalmars-d-learn wrote: [...]
> It happens on a bunch. I do get errors or overlong file names but this doesn't seem to be the case.
> 
> The fact is, that simply using execute shell using the same file name works.  So this is a D problem.
> 
> It happens quite often and every time I can delete the files in file explorer.

It would really help if you post a stripped-down version of the code that exhibits the same problem.  Otherwise we're just guessing what the real problem is.


T

-- 
It only takes one twig to burn down a forest.

On Friday, 14 September 2018 at 15:21:21 UTC, H. S. Teoh wrote:
> On Fri, Sep 14, 2018 at 02:36:34PM +0000, Josphe Brigmo via Digitalmars-d-learn wrote: [...]
>> It happens on a bunch. I do get errors or overlong file names but this doesn't seem to be the case.
>> 
>> The fact is, that simply using execute shell using the same file name works.  So this is a D problem.
>> 
>> It happens quite often and every time I can delete the files in file explorer.
>
> It would really help if you post a stripped-down version of the code that exhibits the same problem.  Otherwise we're just guessing what the real problem is.
>
>
> T

It woudln't help. I'm dealing with over a million files and you'd need those files too.

But basically all I have done is created a new rename function:

void removeFile(string fn)
{
	if (!isDir(fn))
	{
		// remove(fn)
		setAttributes(fn, 0x80);
		auto ls = executeShell(`del /F /Q "`~fn~`"`);
		if (ls.status != 0) throw new Exception("Cannot delete file `"~fn~"`!");
	}
}

And this works and functions appropriately.

The other code is basically just recursively going through the directory as standard practice using dirEntries and deleting certain files(it's a little more complex since there is some logic on the file name, but nothing touches the file except delete).

On Friday, 14 September 2018 at 16:55:21 UTC, Josphe Brigmo wrote:
> On Friday, 14 September 2018 at 15:21:21 UTC, H. S. Teoh wrote:
>> [...]
>
> It woudln't help. I'm dealing with over a million files and you'd need those files too.
>
> But basically all I have done is created a new rename function:
>
> void removeFile(string fn)
> {
> 	if (!isDir(fn))
> 	{
> 		// remove(fn)
> 		setAttributes(fn, 0x80);
> 		auto ls = executeShell(`del /F /Q "`~fn~`"`);
> 		if (ls.status != 0) throw new Exception("Cannot delete file `"~fn~"`!");
> 	}
> }
>
> And this works and functions appropriately.
>
> The other code is basically just recursively going through the directory as standard practice using dirEntries and deleting certain files(it's a little more complex since there is some logic on the file name, but nothing touches the file except delete).

Went ahead and did the following in case anyone comes across your issue in the future:

https://github.com/dlang/phobos/pull/6707

That way the documentation will at least be clear about it.