Fix #18 – Last modified date isn't preserved when copying file to file share #24
Conversation
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
The NTProtocolHandler already does this when a NetworkFile object is available, so for consistency do this in the CoreProtocolHandler, too.
Incrementing the write count on a network file marks the last modified date as dirty. In order to reset the flag back to clean, we need to attempt applying any date changes happening via setFileInformation() to the corresponding network file, too.
…irty Also just to be on the safe side, update the network file, too, in order to reset the tracking flack back to clean.
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.
This is a tentative fix for issue #18.
The idea is to track the dirty state of the last modified date via a boolean on the
NetworkFile, so incrementing the write counter sets the flag to dirty and manually updating the last modified date sets it back to clean, and then on file close the last modified date is only automatically updated if it's marked as dirty.It's not completely perfect, because it seems that depending on the caller it's not always possible to retrieve the corresponding
NetworkFilefrom inside aDiskInterface.setFileinformationcall, and therefore reset the tracking flag back to clean, but at least for SMBv1 traffic from a Windows client it seems to work fine. (Hopefully it'd also work for the SMBv2 implementation, because I can't test that one.)