Loading Profile...
trailing zero (null)-terminated textfiles when clicking directly in wuala-client (using notepad++ on windows xp 32bit)
i have been wondering (on luzius changelog files (txt-files)) for some time whats happening with those padded/trailing zero/null at the end of textfiles.
whenever i view for example any textfile in
http://wua.la/Luzius/Documents/Wuala/... and i doubleclick them in the win32 wuala client on win32 (windows xp) my notepad++ (sourceforge project) starts up and displays the file.
but the last several characters of that file are ascii-zero/null... i have also created a very simple test-textfile and tried it myself. the zeros get somehow generated when using doubleclick....
but when i drag the file from wuala to my desktop again and md5sum/bytecompare that dragged text-file with the original textfile (which ofcourse didnt have any trailing/padding zeros) then everything is fine, so no zeros/trails there, the two files are the same size, same content same everything.
what is wrong here? is the doubleclick unrealible? is doubleclicking doing something else on textfiles than a normal download/dragdrop?
thanks and cheers.
whenever i view for example any textfile in
http://wua.la/Luzius/Documents/Wuala/... and i doubleclick them in the win32 wuala client on win32 (windows xp) my notepad++ (sourceforge project) starts up and displays the file.
but the last several characters of that file are ascii-zero/null... i have also created a very simple test-textfile and tried it myself. the zeros get somehow generated when using doubleclick....
but when i drag the file from wuala to my desktop again and md5sum/bytecompare that dragged text-file with the original textfile (which ofcourse didnt have any trailing/padding zeros) then everything is fine, so no zeros/trails there, the two files are the same size, same content same everything.
what is wrong here? is the doubleclick unrealible? is doubleclicking doing something else on textfiles than a normal download/dragdrop?
thanks and cheers.
1
person has this problem
I have this problem, too!
Tell me when someone solves it.
The more people who report this problem, the more it gets noticed.
The more people who report this problem, the more it gets noticed.
Create a customer community for your own organization
Plans starting at $19/month
-
Inappropriate?This will be fixed with the next update. The problem was that Wuala returned the correct file size when asked, but when a program tries to read more bytes than this size, Wuala did not say 'End-of-file' but continued reading up to 16 null-bytes. So all programs that just read until they reached 'End-of-file' got some null-bytes at the end, while programs that look at the file-size information (e.g. the file explorer responsible for the drag & drop) read the files correctly. That's why you got different results with different methods. :)
2 people say
this solves the problem
EMPLOYEE
