-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Replace MDir with mixxx::FileInfo/FileAccess #3744
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have test tested this on Ubuntu and it still works. Thank you.
How do want to proceeded with the MacOS tests. Can we take the risk an and merge it without?
@@ -49,7 +49,7 @@ class BrowseThread : public QThread { | |||
|
|||
// You must hold m_path_mutex to touch m_path or m_model_observer | |||
QMutex m_path_mutex; | |||
MDir m_path; | |||
mixxx::FileAccess m_path; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks confusing, because one may think this refrences a file, but it is a directory. Do you have an idea to improve the naming?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
QFileInfo also could reference everything file/dir/symlink, we follow it. This naming is at least consistent.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I know. Unfortunately this makes the usage code harder to read.
Can we rename m_pPath to something more specific, to improve the situation?
Do we use the security tokens for single files? Looking into the implementation, there are different call stacks for files and directories. Maybe we can inherit a file and a dir version and accept some code duplications for some extra safety
What are your future plans with this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is nothing that blocks this PR ...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have just noticed this. The special QDir
overloads in Sandbox
are not needed an can be removed. We can switch entirely to mixxx::FileInfo
. Only the browse view seems to be affected.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Inheriting does not make sense for this use case. You can only know at runtime if a file system reference is a file, directory, or symlink.
The equivalent of QFileInfo
in Rust would be std::path::Path
/std::path::PathBuf
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just noticed that Sandbox
handles directories differently. Converting back to draft until I have checked that nothing got mixed up here. Thanks for reviewing so far.
->getDirectoryDAO() | ||
.getDirs(); | ||
for (const auto& dir : dirs) { | ||
const auto dirInfos = m_pTrackCollectionManager->internalCollection() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
const auto dirInfos = m_pTrackCollectionManager->internalCollection() | |
const QList<mixxx::FileInfo> dirInfos = m_pTrackCollectionManager->internalCollection() |
We don`t have a DirInfos class or such. That's why I think we we need to be here more verbose here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did you check consider this comment?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have explicitly added the type for the loop variable (even though I don't consider it as relevant and everything was declared as auto
before). It doesn't matter that the container is a QList, we just iterate through it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Now with tests for directory links (not on Windows) and explicit distinction of directory vs. file sandboxing. Just to be sure that we don't break anything. The code in |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Works fine for me, tests pass.
@daschuer Can I hit merge or are you planning to review this again? |
If you have reviewed and tested it, it should be sufficient, however a test on a mac would be nice. |
No, maybe @Be-ing can help out. |
@@ -49,7 +49,7 @@ class BrowseThread : public QThread { | |||
|
|||
// You must hold m_path_mutex to touch m_path or m_model_observer | |||
QMutex m_path_mutex; | |||
MDir m_path; | |||
mixxx::FileAccess m_path; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about this:
mixxx::FileAccess m_path; | |
mixxx::FileAccess m_dir; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't want to introduce many unrelated changes just by renaming things. And I especially try to avoid touching this browse stuff.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Works well, thank you!
Next step towards replacing
TrackFile
and a more cohesive handling of sandboxing:mixxx::FileAccess
=mixxx::FileInfo
+SecurityTokenPointer
DirectoryDAO
DirectoryDAO
fromLibrary
intoTrackCollection
which ownsDirectoryDAO
mixxx::FileInfo
MDir
The next PR will improve sandboxing based on this foundation and finally remove
TrackFile
.Unfortunately I am unable to split these changes into even smaller change sets afterwards. There is also some overlap between the current and the following changes. Just trying to keep it as small as possible after holding those PRs back for such a long time. For all new code I try to submit tiny PRs, one at a time.