Impossible to move/rename files with dokan_fuse wrapper. #178
Comments
|
this is what happens when i delete a file from the command window. |
|
when deleting file "test" using commandline: |
|
@g3gg0 , This issue is about rename. Do you have a problem with remove ? |
|
for delete it seems to be some other issue. i create a file using but something's wrong in my code as it seems :) http://pastebin.com/7PL4MafM |
|
The rename function had no issue. It has been fixed by The fuse wrapper should be updated to the new API version. I create another issue related to it. @g3gg0 , I think this come from your code yes. I remade the test with the fuse mirror and it worked 😢 If you can reproduce the issue with the fuse mirror feel free to open a new issue. |
|
ok fixed that issue i wrote before. problem persists. thing is, our fuse code is not allowed to keep an open'ed file handle opened when using dokany. background is: the FUSE doc says that the fuse_operations "should work very similar" to the known unix functions. solutions: |
|
@g3gg0 , I see your point of view and I agree that there is a issue with delete unlink since Windows work differently with the handle. However, in the fuse documentation it say Otherwise I am just wondering if there is not a possibility to get the information that the file is going to be delete and in this case to not open. It would fix the issue. |
|
nah this workaround wouldnt fix the issue. it would just make it more rare i didnt say that the fusexmp is doing it wrong, it is just not covering all possibilities and therefore isnt a proper "single" test case in my opinion. it just tests a subset of the features. to be honest, i don't see a proper clean solution. its the open() windows call that is the culprit. |
|
There could be probably some hack to do but I have nothing in mind for now so I added informations in the Wiki about it. |
|
yeah very good idea :) |
|
Windows does not usually allow a file to be deleted when it is open, and deleting a file always operates on an open file. Renaming also counts as deleting. You would need to alter the calls from open() to CreateFile() and always include FILE_SHARE_READ|FILE_SHARE_DELETE (and possibly |FILE_SHARE_WRITE, though that's perhaps another argument) in dwShareMode. |
|
Hi @kyanha , This could be an idea but it would mean that all your files can be remove at any moment without any restrictions. |
|
I am confused. What part of renaming is denied by the operating system? If my virtual filesystem internally just update some data structures in memory, will the renaming of opened files still be an issue? |
|
@netheril96 In your case (data structures in memory), there is going to be no issue. |
|
Catching up on this thread (and Dokan in general). What @netheril96 describes is indeed possible -- it is just a fair amount of work to do completely. In fact the WSL people at Microsoft have done a fairly good job of it in the kernel; there is a write-up here. Basically if you want Linux-like behavior, you would have to build a Linux-like VFS with fake inodes and then operate on those not the NTFS objects. Doable, but hard. |
There is an issue whit the dokan_fuse wrapper, you get an error when you try to move/rename files.
This can easily be reproduce with the fuse_mirror.
To know what is happening wrong in the wrapper. We need to see what is the difference in the calls order and result between the C mirror and with the dokanfuse.
I think there is something that the dokanfuse handle wrong (for example return error where it should succeed or something like).
Build info
https:/dokan-dev/dokany/wiki/FUSE#cygwin
The text was updated successfully, but these errors were encountered: