fix: update vm_config.json instead of recreating file#38
Open
sysedwinistrator wants to merge 1 commit intonix-community:trunkfrom
Open
fix: update vm_config.json instead of recreating file#38sysedwinistrator wants to merge 1 commit intonix-community:trunkfrom
sysedwinistrator wants to merge 1 commit intonix-community:trunkfrom
Conversation
When mv overwrites a file, it will remove the destination file and replace it with the source file (in case it is on the same filesystem, in which it will use the source file's inode) or with a new file that has the content of the source file (if the source file is on another filesystem, in which case it will remove the source after copying it). For some reason, the mounted filesystem (VirtioFS IIRC) that contains the vm_config.json does not like it being replaced, and it is impossible to write the new file after the old one has been deleted. (n=1, this has been my experience but I don't have a source link and haven't tried to reproduce it). What works, however, is updating the contents of vm_config.json by opening the existing file, truncating it, and writing the content of our source file to it. Note: while cp (at least the one from coreutils) exhibits the same behavior by default (but can recreate files when using -f/--force), using the shell redirection here makes clear what is going on. Note 2: Yes, it's possible to do this entirely with shell redirects in the form of `>dst <src` (or the other way around), but `cat` is what everybody knows and loves.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Note
I noticed this issue a while ago, but I have neither tried to reproduce it since nor have I actually tested my fix yet (both would require re-installing the VM, which takes a lot of time with my NixOS configuration).
I thought I'd leave it here in case anybody else is encountering the same issue. Also I will forget about it again otherwise 🙈
Commit message
When mv overwrites a file, it will remove the destination file and replace it with the source file (in case it is on the same filesystem, in which it will use the source file's inode) or with a new file that has the content of the source file (if the source file is on another filesystem, in which case it will remove the source after copying it).
For some reason, the mounted filesystem (VirtioFS IIRC) that contains the vm_config.json does not like it being replaced, and it is impossible to write the new file after the old one has been deleted. (n=1, this has been my experience but I don't have a source link and haven't tried to reproduce it).
What works, however, is updating the contents of vm_config.json by opening the existing file, truncating it, and writing the content of our source file to it.
Note: while cp (at least the one from coreutils) exhibits the same behavior by default (but can recreate files when using -f/--force), using the shell redirection here makes clear what is going on.
Note 2: Yes, it's possible to do this entirely with shell redirects in the form of
>dst <src(or the other way around), butcatis what everybody knows and loves.