GNU Core Utilities - Support: sr #106582, call fsync() after cross-device...
You are not allowed to post comments on this tracker with your current authentication level.
sr #106582: call fsync() after cross-device move with mv
Submitter: | None | ||
Submitted: | Sun 14 Dec 2008 01:07:23 AM UTC | ||
Category: | None | Priority: | 5 - Normal |
Severity: | 1 - Wish | Status: | None |
Privacy: | Public | Assigned to: | None |
Originator Email: | -email is unavailable- | Open/Closed: | Open |
Operating System: | GNU/Linux |
Attached Files
file #17054: mv.diff added by None (1KiB - application/octet-stream)
Depends on the following items: None found
Items that depend on this one: None found
Carbon-Copy List
There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.
Follows 1 latest change.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2008-12-14 | None | Attached File | - | ![]() |
Added mv.diff, #17054 |
Powered by Savane 3.12.
Corresponding source code
In the event that power is lost immediately following a cross-device move, data can be irrevocably lost, if it has not yet been physically written to disk. This is not typically a problem with an intra-device move, since any data loss will be mitigated by the filesystem's journal.
A simple solution is to have the mv tool call fsync() on the newly created destination file in the case of a cross-device move before deleting the source file. This ensures that the data is physically on at least one of the target or source media at all times. One step further could be even to instruct the drive to flush its write buffer, but this is OS-dependent.
The reason I believe this should be part of mv and not a wrapper is that mv already performs checks whether the move is cross-device, and there is no trivial way to do so in e.g. a shell script.
Attached is a diff implementing this in mv.