Comments (8)
Thanks for this suggestion!
Some possible solutions discussed in dokan-dev/dokany#51
Originally posted by @overheadhunter in https://github.com/cryptomator/dokany-nio-adapter/issues/36#issuecomment-609583179
There are different approaches to achieve this:
- Over the registry
- only for the current user:
- for all users
- Over a certain file:
- via an autorun.inf file
- via the desktop.ini file
Since a vault can be mounted as a volume or as folder, we should check if one of the above methods covers both.
Some thougts:
Method 1.ii is the least acceptable, since it needs admin rights and thus not really useable for us.
Method 1.i is from my point of view the preferred one, since we only need to execute one command for setting or unsetting (using reg )
The filebased methods are from my point of view not the right tool, because Cryptomator is a os independet tool and we would need to place some files inside a vault only for windows. This can confuse users and they can accidently delete them.
from dokany-nio-adapter.
How would you change the icon for a drive via registry?
I only came across the solution facilitating the desktop ini file, which we could simply add to the dir listing of the root directory.
from dokany-nio-adapter.
How would you change the icon for a drive via registry?
See for example here: https://www.tenforums.com/tutorials/74659-change-drive-icon-windows-10-a.html#option3
What do you mean add to the dir listing? Like sideloading the file from another location? And nonetheless the user would see this file and be able to interact it, which they shouldn't imho.
from dokany-nio-adapter.
user would see this file and be able to interact it, which they shouldn't imho
Why not?
from dokany-nio-adapter.
Because this is adapter specifc stuff, the end-user of any application, which uses this adpater, should not be able to alter anything here except through an intended way by a developer. (at least not in an easy way) But since this file is added to the directory listing, it is visible and hence, can be possible altered.
Also, due to the sideloading it is not clear how to handle this alteration process. We need to add a filtering to all other methods if we want to prevent it. Or need a case distinction between this special file and all other files.
Additionally think about the implications specifically for Cryptomator:
- A vault contains only encrypted data
- Using this adpater to serve this vault shows inside your vault data that is not encrypted.
- What if someone altered this side-loaded data? Made it executable? Maybe even replaced with Maleware? And it is still shown inside a "secure" vault
The last two points are of course only valid, if we use this "side-loading" strategy. But if we do not have a file system which is backed up by file storage (e.g. database), i cannot imagine any other way to do it.
from dokany-nio-adapter.
In my opinion it is very much intended by the developer that the user can add a desktop.ini file. For us, any file should only be a file, we should not distinguish it.
If the user writes such a file, dokany-nio-adapter passes it through to the underlying file system.
If the user attempts to read this file (and it exists), dokany-nio-adapter reads it from the underlying file system.
Only if it doesn't exist, it will "add" it. Kind of like OverlayFS works but with a precedence for the underlying file.
from dokany-nio-adapter.
Ah, sorry, i forgot that this is not the dokan-java projekt and just an dokan adapter for the nio-interface of Java, therefore we will always have a filesystem/ file storage.
But since this is only a nio-adapter, don't we violate the contract of the interface by showing files which do not belong to the underlying filesystem?
In my opinion it is very much intended by the developer that the user can add a desktop.ini file. For us, any file should only be a file, we should not distinguish it.
If the user writes such a file, dokany-nio-adapter passes it through to the underlying file system.
If the user attempts to read this file (and it exists), dokany-nio-adapter reads it from the underlying file system.
I agree with you here. If we decide to use the registry solution we should research what the precedence is.
For the "overlay" solution the handling question persits: How to handle calls like move/write/delete onto such "not existing" file? We cannot block them, we need to return some code. Success or a specific error?
from dokany-nio-adapter.
How to handle calls like move/write/delete onto such "not existing" file?
Legitimate to ask this for move/delete. Regarding write, I'd say the user is allowed to write through to the underlying file system, thus creating an "existing" file.
don't we violate the contract of the interface by showing files which do not belong to the underlying filesystem?
This is after all an optional feature. I don't want this library to add a "Cryptomator Icon", but rather add a Map<Path, byte[]> overlayFiles
containing file contents to show for certain paths, which will be empty by default.
Of course, we need to thoroughly document the exact behaviour
Underlying File Exists | Underlying File is Absent | |
---|---|---|
Read | Read underlying file | Read from overlay map |
Write | Write to underlying file | Write to underlying file |
Delete | Delete underlying file | no-op? TBD |
Move from | Move underlying file | TBD |
Move to | Move to underlying file | Move to underlying file |
... |
from dokany-nio-adapter.
Related Issues (20)
- Add option to use custom mount options HOT 2
- Migration to JDK 11 HOT 1
- Very slow writing speed / Always synchronised writing HOT 1
- Wrong UNC name HOT 3
- Shutdown hook never invoked
- Handling of `FILE_NO_INTERMEDIATE_BUFFERING` HOT 1
- Too Long File Names Error Code Support
- Google Drive File Stream: Certain applications do not write to file HOT 6
- Add method to API to check if there are open handles
- Windows CMD access the wrong folder HOT 1
- Windows tool XCOPY: File metadata preservation issue
- FindFilesWithPattern: Wrong pattern matching HOT 1
- Unable to stream video files with VLC HOT 1
- Impossible to mount more filesystems than number of CPU cores HOT 1
- Delegate revealing a drive to the API consumer HOT 3
- Default mount options are used if none are given HOT 1
- Observe status of mounted filesystem
- Relax condition of successful mount
- Migrate to Dokany 2.x HOT 12
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from dokany-nio-adapter.