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

Opening file for write without append fails to truncate it, old data left at EOF #25

Closed
dcoshea opened this issue Apr 15, 2022 · 2 comments
Assignees
Labels
bug Something isn't working

Comments

@dcoshea
Copy link

dcoshea commented Apr 15, 2022

With pyfatfs checked out from the bugfix/dentry_ordering branch as at 96ae6bc, with an MS-DOS 5 floppy image (probably the filesystem contents don't matter though), if I create a file and then overwrite it with less data, the old content remains at the end of the file:

>>> fs.writetext("/testfile", "1234567890")
>>> fs.writetext("/testfile", "abcd")
>>> fs.readtext("/testfile")
'abcd567890'

This test passes with fs.memoryfs.MemoryFS.

I assume that any case where a file is opened for write but not for append can trigger this bug.

I suspect that pyfatfs.FatIO.FatIO.__init__() needs to call truncate() when self.mode.truncate is True like fs.memoryfs.MemoryFile.__init__() does.

nathanhi added a commit that referenced this issue Apr 15, 2022
When opening a file with truncate mode configured
the truncate call was missing from the `FatIO` c'tor,
thus leaving files with previous content in them.
@nathanhi
Copy link
Owner

Fixed on master, will be part of the upcoming bugfix release.

nathanhi added a commit that referenced this issue Apr 15, 2022
When opening a file with truncate mode configured
the truncate call was missing from the `FatIO` c'tor,
thus leaving files with previous content in them.
@nathanhi nathanhi added the bug Something isn't working label Apr 15, 2022
@nathanhi nathanhi self-assigned this Apr 15, 2022
@dcoshea
Copy link
Author

dcoshea commented Apr 17, 2022

Thanks! I verified that the issue I was having has gone away in v1.0.5 and I was able to revert my workaround of removing the file before calling writetext().

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants