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
{{ message }}
This repository has been archived by the owner on Jan 6, 2020. It is now read-only.
The fix for issue maidsafe-archive/MaidSafe#68 introduced a problem when a file is copied to the drive. Typically CbFsSetEndOfFile is called before writing to a file, this subsequently calls the truncate method in self encryption, resulting in, if the new end of file is greater than the current, the new end of file size minus the current file size null bytes being written. If the file size is zero and CbFsSetEndOfFile is passed the true end of file the process will write the whole file in self encryption as if the file contained all null bytes before the OS writes the actual constituents of the file. When the actual constituents are written self encryption's sequencer stores all the data in memory and if the file is large eventually runs out and a bad_alloc exception is thrown. For all smaller files this is why we are seeing an exponential increase in write times with respect to file size. Commit maidsafe-archive/MaidSafe@f5b8fea fixes the problem, on Windows at least, when the file size is initially zero since the file is then written sequentially and the time is dramatically reduced.
When extracting the files in a compressed archive, however, we get alternating calls to CbFsSetEndOfFile and CbFsWriteFile. In this case, after the first cycle, the file size is non-zero so that null bytes are written up to the new file size then they're overwritten with the actual data.
The text was updated successfully, but these errors were encountered:
Migrated from maidsafe-archive/MaidSafe#73
The fix for issue maidsafe-archive/MaidSafe#68 introduced a problem when a file is copied to the drive. Typically CbFsSetEndOfFile is called before writing to a file, this subsequently calls the truncate method in self encryption, resulting in, if the new end of file is greater than the current, the new end of file size minus the current file size null bytes being written. If the file size is zero and CbFsSetEndOfFile is passed the true end of file the process will write the whole file in self encryption as if the file contained all null bytes before the OS writes the actual constituents of the file. When the actual constituents are written self encryption's sequencer stores all the data in memory and if the file is large eventually runs out and a bad_alloc exception is thrown. For all smaller files this is why we are seeing an exponential increase in write times with respect to file size. Commit maidsafe-archive/MaidSafe@f5b8fea fixes the problem, on Windows at least, when the file size is initially zero since the file is then written sequentially and the time is dramatically reduced.
When extracting the files in a compressed archive, however, we get alternating calls to CbFsSetEndOfFile and CbFsWriteFile. In this case, after the first cycle, the file size is non-zero so that null bytes are written up to the new file size then they're overwritten with the actual data.
The text was updated successfully, but these errors were encountered: