maidsafe-archive/maidsafe-encrypt

MaidSafe Encrypt implements functions related to "self-encryption" of files and folders.

maidsafe-encrypt's Issues

Skipping un-changed chunk cause the predecessor chunks non-stroed (updated)

Scenario :
Populate encrypt stream with all zero data.
Later on re-write all content, with part content remains same.

Result :
Some chunks (the chunks just before the remains same chunk) got no stored (updated),
although it shall be updated.

Test Code :
branch : core_issue_large_file
Test : BEH_Bugs / test 2 -- skipping

Reason and Temporary Solution :
In FinaliseWriting, return immediately once un-changed detected, without storing the current chunk's pre-predecessor chunk.
The problem can be overcome by just comment out the early return, as shown in the commit of :
1246ed9
However, this may slow the performance, so further investigation is required.

Read pass EOF

This is regarding the code of
bool SelfEncryptor::Read(char* data, uint32_t length, uint64_t position) {
...
if ((position + length) > file_size_)
return false;
...
}

In Linux, reading a file will be performed as reading block by block (4kb) till pass the EOF.
However the above code forbids access pattern like this, and will give a wrong result (causing an exception to be thrown in drive code)
drive/drive.h:305] For "/SqYlG.txt", reading 4096 of 516177 bytes at offset 516096
drive/unix_drive.h:744] Failed to read /SqYlG.txt: Unknown error in Common

Most of filesystem tests with --local flag failed due to this.

Updating a chunk sharing with multiple data_maps causes problem

This is related to the Issue 21 in Drive, corrupted file when modify one of the same content files.

New test is added by the commit :
c0053a8
to show the problem.

Broken link in wiki

Hm, I can't seem to offer edits or pull requests to the wiki, so I'm opening an issue to tell you that on this page:

https://github.com/maidsafe/MaidSafe-Encrypt/wiki/Documentation

The first paragraph links to a dead video link, reproduced below:

MaidSafe-Encrypt implements functions related to 'self-encryption' of files and folders. This video provides a brief overview of the process.

AFAICT, the video is not on maidsafe.net at all, so it should either be restored to that page, or the link changed, perhaps to https://www.youtube.com/watch?v=Jnvwv4z17b4

Dashboard script not catching an error installing Encrypt

Environment

Windows 7 (32bit), Visual Studio 2010, Cmake 2.8.4

Issue

When you attempt to install Maidsafe-Encrypt in either release or debug an error occurs (error can be found at the stacktrace section of this report).

The problem is the dashboard script (MaidSafe-Common\installed\share\maidsafe\cmake_modules/maidsafe_dashboard.cmake) doesn't catch this error, and submits results to the dashboard as if the project has correctly installed.

We should catch the error and report it correctly, as later project which depend upon Encrypt being installed, fail to build as they notice Encrypt isn't installed.

Stacktrace

c:\nightly\MaidSafe-Encrypt\build\Win_MSVC>cmake --build . --config Release --ta
rget install

Microsoft (R) Visual C++ 2010 Express Version 10.0.30319.1.
Copyright (C) Microsoft Corp. All rights reserved.

Invalid Command Line. Unknown Switch : p:Configuration=Release.

Use:
vcexpress [solutionfile | projectfile | anyfile.ext] [switches]

The first argument for vcexpress is usually a solution file or project file.
You can also use any other file as the first argument if you want to have the
file open automatically in an editor. When you enter a project file, the IDE
looks for an .sln file with the same base name as the project file in the
parent directory for the project file. If no such .sln file exists, then the
IDE looks for a single .sln file that references the project. If no such single
.sln file exists, then the IDE creates an unsaved solution with a default .sln
file name that has the same base name as the project file.

Command line builds:
vcexpress solutionfile.sln /build [ solutionconfig ] [ /project projectnameorfil
e [ /projectconfig name ] ]
Available command line switches:

/Log Logs IDE activity to the specified file for troubleshooting.
/ResetSettings Restores the IDE's default settings, optionally resets to
the specified VSSettings file.
/SafeMode Launches the IDE in safe mode loading minimal windows.

Product-specific switches:

/debugexe Open the specified executable to be debugged. The
remainder of the command line is passed to this
executable as its arguments.
/useenv Use PATH, INCLUDE, LIBPATH, and LIB environment variables
instead of IDE paths for VC++ builds.

To attach the debugger from the command line, use:
VsJITDebugger.exe -p

c:\nightly\MaidSafe-Encrypt\build\Win_MSVC>

Tests fail on single-core machine

See http://dash.maidsafe.net/viewTest.php?onlyfailed&buildid=15976 for example of failures.

Compressed archive files are written ~twice when unzipping.

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.