Skip to content

Conversation

@mscheltienne
Copy link
Contributor

Hi! I would like to propose a small additional feature: the possibility to overwrite an existing file. This would be handy as I am adding the overwrite argument to MNE export function in this PR: mne-tools/mne-python#9975

For now, the PR will delete existing files if overwrite is set to True, which is not really a clean way of doing it. The possibility to set overwrite upstream would be appreciated.

You can find the minimal changes I think are necessary to add this feature. I am not familiar with mffpy and I might have overlooked something. Please let me know!

@jusjusjus
Copy link
Collaborator

Hi @mscheltienne, your suggestion makes sense to me. Thanks. However, I'm worried that as a result of your implementation some, e.g., Event files wouldn't be overwritten, but just remained astray from the old MFF. I propose to cleanly unlink the whole MFF dir if it already exists. What do you think?

@mscheltienne
Copy link
Contributor Author

@jusjusjus Glad to hear that you like it.

As I expected, I don't know enough about mffpy to cleanly implement it. You know better than me how to properly overwrite the writer output; so you are definitely right.
I will check tomorrow more in detail to figure out what is created by the writer and what should be removed, and I'll update the proposal accordingly.

@mscheltienne
Copy link
Contributor Author

What do you mean by unlink? I just had a quick second look at the writer code, and your remark is sound.
How about:

If filename already exists and overwrite is True: list the files in mffdir; overwrite the one to overwrite and delete the one that were not overwritten?

@jusjusjus
Copy link
Collaborator

@ephathaway, let's discuss how this API should look like.

@ephathaway
Copy link
Member

@mscheltienne, @jusjusjus, so sorry I am just now responding to this.

If filename already exists and overwrite is True: list the files in mffdir; overwrite the one to overwrite and delete the one that were not overwritten?

This sounds like a good solution. We could add a cleanup step to Writer.write which deletes any files in the output directory that are not in Writer.files.

@mscheltienne
Copy link
Contributor Author

mscheltienne commented Apr 2, 2022

Hey, this PR was kind of forgotten. I really don't know much about mffpy, and I haven't tested the changes I made; but based on the code and on the conversation here, this last commit should address your concerns.

Could you spend the time to finalize this one?

@jusjusjus jusjusjus requested a review from ephathaway April 4, 2022 09:56
Copy link
Member

@ephathaway ephathaway left a comment

Choose a reason for hiding this comment

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

Hi @mscheltienne, thanks for your contribution. With the requested changes, it should work as expected.

@mscheltienne
Copy link
Contributor Author

@ephathaway Done

Copy link
Member

@ephathaway ephathaway left a comment

Choose a reason for hiding this comment

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

So we need to account for the overwrite .mfz edge case. Currently, attempting to overwrite a .mfz file errors out because the 'mffdir' is removed (filename + .mff), but the zipped MFF is not removed (filename + .mfz). We will need to add some logic to remove both filename.mff and filename.mfz.

mscheltienne and others added 3 commits April 20, 2022 10:18
Co-authored-by: Evan Hathaway <42755980+ephathaway@users.noreply.github.com>
@mscheltienne
Copy link
Contributor Author

Done. As there is no writer test to .mfz, I based my edit on your comment:

(filename + .mff) [...] (filename + .mfz)

@ephathaway ephathaway merged commit 5fc4ae7 into BEL-Public:develop May 5, 2022
@ephathaway
Copy link
Member

@mscheltienne, thanks for your contribution! We will cut a new release with this feature.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants