[Vm-dev] FilePlugin can't delete files with 0444

Max Leske maxleske at gmail.com
Tue Oct 13 15:51:23 UTC 2015


> On 13 Oct 2015, at 17:14, vm-dev-request at lists.squeakfoundation.org wrote:
> 
>> 
>> 
>> Hi.
>> 
>> Git creates it’s object files (the object database files) with permission
>> 0444 (i.e. no write permissions). On OS X and Linux the VM is happy to
>> delete those files but on Windows 7 the FilePlugin fails with a
>> #primitiveFailed:.
>> 
>> Before I dive into the code and start fixing stuff I wanted to know if
>> this is a known issue / unfixable problem.
>> 
> 
> Yes, I saw this already when working with git directories for the long path
> issue.
> On windows, we'll have to remove a readonly  attribute if we want to delete
> read-only files.
> 
> Don't know how to fix this, silently in the vm if the plugin failed? Or
> return with an appropriate return code and
> give the image a chance to ask the user and then call the delete method
> again with a flag "do-delete-readonly-files"
> Or add a method to the plugin, to change the attributes and change add code
> in the image to provide a method that changes
> readonly flags for all entries prior to calling deleteAll?
> 
> 

In my opinion the behaviour should be identical on Windows and on *nix. The point is, I think, that a read only file which belongs to the current user is effectively writeable. The missing write bit simply states that the file is private and should not be deleted lightly. From that point of view the VM does the right thing on *nix (I didn’t test this but I’d expect the primitive to fail aswell if the current user were *not* the owner of the file). Also, this is a case where one could simply supply ‘-f’ to ‘rm’ on the command line, but FilePlugin has no notion of forcing deletion. So either we add a “forceDeletePrimitive” or we make sure that the primitive works the same way on both systems.

And yes, I’d rather have a nice error than a #primitiveFailed, but that’s the FileDirectory / FileStream / FileSystem code, not FilePlugin.

Cheers,
Max

> 
> 
> 
> 
> 
>> 
>> Cheers,
>> Max

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20151013/427d3368/attachment.htm


More information about the Vm-dev mailing list