Skip to content
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

Add mixxx::FileInfo for file system references #3741

Merged
merged 9 commits into from
Mar 23, 2021
Merged

Add mixxx::FileInfo for file system references #3741

merged 9 commits into from
Mar 23, 2021

Conversation

uklotzde
Copy link
Contributor

Add a wrapper mixxx::FileInfo that acts as a shim for QFileInfo with a reduced API and Mixxx-specific extensions. It introduces the concept of a "location" for permanent, normalized file/directory/symlink references that are used in many places in Mixxx. Supposed to replace both TrackFile and MDir. Please refer to the code for more detailed documentation.

This is only the first PR in a row. If you want to see this class in action please check #2656.

@uklotzde uklotzde added this to the 2.4.0 milestone Mar 22, 2021
@github-actions github-actions bot added the build label Mar 22, 2021
Copy link
Member

@daschuer daschuer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have left some comments.
I have not yet get the point where it helps in:
#2656
Can you print me to a place?

namespace mixxx {

/// Helper functions and extensions for QFileInfo using Mixxx terminology.
namespace fileinfo {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Having a namespace in addition to a class would be a new concept in Mixxx, and will probably hide the function from intellisense feature of the IDE.

I would prefere to make them static class members.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How would you then name those static functions to resolve the naming conflicts?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can have a static and a non static function with the same name, because the parameters are different.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

QSting location = AbsoluteFileInfo::location(file);

Looks Ok to me.

The purpose of the assert inside would be obvious. No need to a extra comment.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The property of being not relative is not a class invariant. Instead this must be determined at runtime whenver you try to obtain a location string.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How could it happen that it changes after the QFileObject is constructed?
I am unsure how this relates to my interface proposal, because it just showsa rename and a move into the class namespace.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please note that only some mixxx::FileInfo instances will be converted into location strings. This must only be checked when you try to obtain a location, not in the constructor.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have left some comments.
I have not yet get the point where it helps in:
#2656
Can you print me to a place?

The subsequent commits in #2656 will make use of this class.

src/util/fileinfo.h Outdated Show resolved Hide resolved
src/util/fileinfo.h Outdated Show resolved Hide resolved
src/util/fileinfo.h Outdated Show resolved Hide resolved
@daschuer
Copy link
Member

Ok, I think I have got it. You want a class that is not a relative File.

Why not just assert this at the constructor and all other non const members.
The class can be called AbsoluteFileInfo to make this clear.

@uklotzde
Copy link
Contributor Author

I

Ok, I think I have got it. You want a class that is not a relative File.

Why not just assert this at the constructor and all other non const members.
The class can be called AbsoluteFileInfo to make this clear.

No. I want a class that reflects the application-level concepts and allows to detect unintended usage, both at compile-time (limited API) and runtime (debug assertions).

Copy link
Member

@daschuer daschuer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you. We are getting close.
Here some more comments.

src/util/fileinfo.h Outdated Show resolved Hide resolved
src/util/fileinfo.h Outdated Show resolved Hide resolved
/// once it has been set, even after the corresponding file has
/// been deleted! A non-empty canonical location is immutable.
/// See also: FileInfoTest
QString freshCanonicalLocation();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is the immutable issue a Mixxx or Qt issue?
Because of the immutable nature the name is misleading. Do we need the function at all?
Maybe something like
ResolveUnresolved()

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I consider QFileInfo a dangerous and confusing class, mainly caused by the (optional, but default) caching behind the scenes that causes side-effects.

This function has been adopted from TrackFile. It is needed to ensure that previously unavailable locations become accessible when mounting volumes after starting Mixxx. A refresh is only triggered if the first attempt to obtain the canonical location results in an empty string. In this case and if cashing is enabled we need to check the file system again, to ensure that the file is really absent.

Copy link
Contributor Author

@uklotzde uklotzde Mar 22, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The comment already explains the situation in detail and is now verified by an extensive test. I am not investing more time here.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, than this is only a naming issue.
Here:

auto canonicalLocation = fileInfo.freshCanonicalLocation();

all comments here are out of sight and you have placed another comment to explain the function again.

I think the function should be called like:

canonicalLocationFromCashOrRetryLookUp()
or
canonicalLocationRefresIfEmpty()

less exact but more catchy:

originalCanonicalLocation()

or we may split it up in too calls()

fileinfo.resolveUnresolved()
return fileinfo.canonicaLocation()

We remove the function her and inline it.

src/util/fileinfo.h Show resolved Hide resolved
@uklotzde
Copy link
Contributor Author

The next 2 commits will remove MDir and wrap mixxx::FileInfo + SecurityTokenPointer into mixxx::FileAccess. Removing TrackFile will happen after this is done.

/// once it has been set, even after the corresponding file has
/// been deleted! A non-empty canonical location is immutable.
/// See also: FileInfoTest
QString freshCanonicalLocation();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, than this is only a naming issue.
Here:

auto canonicalLocation = fileInfo.freshCanonicalLocation();

all comments here are out of sight and you have placed another comment to explain the function again.

I think the function should be called like:

canonicalLocationFromCashOrRetryLookUp()
or
canonicalLocationRefresIfEmpty()

less exact but more catchy:

originalCanonicalLocation()

or we may split it up in too calls()

fileinfo.resolveUnresolved()
return fileinfo.canonicaLocation()

We remove the function her and inline it.

src/util/fileinfo.h Show resolved Hide resolved
@uklotzde
Copy link
Contributor Author

I am not able to change

auto canonicalLocation = fileInfo.freshCanonicalLocation();
until TrackFile has been replaced by mixxx::FileInfo. The legacy class remains as is. I have prepared a commit that will follow in a later PR.

Copy link
Member

@daschuer daschuer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you. Nice result :-)

@daschuer
Copy link
Member

Can this be merged after CI has finished?

@uklotzde
Copy link
Contributor Author

Can this be merged after CI has finished?

Yes. Please wait for CI, I haven't built this locally yet.

@daschuer
Copy link
Member

All Green. Thank you.

@daschuer daschuer merged commit e1f8fea into mixxxdj:main Mar 23, 2021
@uklotzde uklotzde deleted the fileinfo branch March 23, 2021 15:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants