You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
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.
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().
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:
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 calltruncate()
whenself.mode.truncate
isTrue
likefs.memoryfs.MemoryFile.__init__()
does.The text was updated successfully, but these errors were encountered: