CMS Made Simple Forums

Hello,

Many thanks to the CMSMS folks for all their hard work and for the great CMSMS solution.

I've encountered an odd bug which occurs when a text-based file is uploaded using the File Manager. The glitch can be reproduced as follows:

1. Create a text file locally named "test_upload.txt" and on the first line put the line "TEST01".
2. Upload the file using the File Manager to the /uploads directory.
3. Once the file has been uploaded, use your web browser to view test_upload.txt (i.e. http://[your_domain]/uploads/test_upload.txt).

You should see:
TEST01

4. Edit the local version of test_upload.txt and modify it by leaving the first line blank and putting "TEST02" on the second line.
5. Re-upload the modified test_upload.txt using the File Manager to the /uploads directory.
6. Use your web browser to again view test_upload.txt.

Instead of seeing the expected:
(blank line)
TEST02

you will see:
TEST01
TEST02

This doesn't appear to related to the local browser cache as I've emptied my cache and reloaded the page and still see the odd result.

Also clearing the CMSMS server cache via the CMSMS admin console doesn't seem to rectify the issue.

Interestingly, if I re-upload the modified test_upload.txt a second time, then I get the expected result.

This has been tested using the following web browsers on both Windows 7 and Windows 8:
- Firefox v.25
- IE 9
- IE 10

This bug also occurs on clean installs of the following CMSMS versions (using default modules only):
- 1.11.7
- 1.11.8
- 1.11.9

The above CMSMS versions were tested on both Windows and Linux configurations:

Windows running XAMPP 1.8.3
- Apache 2.4.4
- MySQL 5.6.11
- PHP 5.5.3
- phpMyAdmin 4.0.4
- FileZilla FTP Server 0.9.41
- Tomcat 7.0.42 (with mod_proxy_ajp as connector)
- Strawberry Perl 5.16.3.1 Portable
- XAMPP Control Panel 3.2.1 (from hackattack142)

Linux Hosting at 1&1
- PHP 5.4

I'd appreciate any help or insight.

Thanks!

This has nothing to do with CMSMS. As there is no CMSMS php scripts involved.

You need to double check your .htaccess file.

This has everything to do with CMSMS as the File Manager is part of CMSMS and it uses PHP scripts.

As mentioned in my original post, this issue occurs when using the CMSMS File Manager to upload text files. The issue is reproduce-able using clean, default installs of CMSMS v1.11.7 - v1.11.9.

For the sake of this discussion, I also deleted all .htaccess files from all directories and the issue still manifests itself as described in my original post.

The issue does not occur when using the CMSMS Image Manager to upload the text files. Nor does the issue occur if an external FTP client is used for uploading, such as FileZilla. So I'd suggest the bug appears to be with the CMSMS File Manager.

I followed gazoo's steps fully expecting to see just TEST02. But I see what gazoo reported:
Something appears to be appending the 2nd uploaded file, rather than replacing it. Very odd.

I then continued putting just TEST03 on the third line. That time I saw just TEST03.

Then I put just TEST04 on the fourth line and refreshed; it showed:
So again, appending rather than replacing.

In the admin log I see 4 instances of:

FileManager test_upload.txt uploaded to /home/ctw/public_html/uploads

So nothing unusual there.

It's not a browser issue - when I view the files in cpanel, I see the same as shows in the browser.

No PHP errors recorded.

I used the drag and drop upload method in File Manager.

My local system is Windows Vista. The CMSMS I used was 1.11.7 on Linux with PHP 5.3.24.

Just to check I wasn't going mad, I uploaded TEST05 and TEST06 versions using cpanel, and these both correctly overwrote the file as you would expect.

FWIW, here is my system info:

----------------------------------------------
Cms Version: 1.11.7
Installed Modules:
CMSMailer: 5.2.1
CMSPrinting: 1.0.4
FileManager: 1.4.3
MenuManager: 1.8.5
MicroTiny: 1.2.5
ModuleManager: 1.5.5
News: 2.12.12
Search: 1.7.8
ThemeManager: 1.1.8
Quotes2: 1.0.2
CGExtensions: 1.37.2
CGSimpleSmarty: 1.7
JQueryTools: 1.2.5
Products: 2.19.6
Showtime: 3.3
Archiver: 0.2.6
FormBuilder: 0.7.4
SEOTools2: 1.2.1

Config Information:
php_memory_limit:
process_whole_template:
max_upload_size: 32000000
url_rewriting: mod_rewrite
page_extension:
query_var: page
image_manipulation_prog: GD
auto_alias_content: true
locale:
default_encoding: utf-8
admin_encoding: utf-8
set_names: true

Php Information:
phpversion: 5.3.24
md5_function: On (True)
gd_version: 2
tempnam_function: On (True)
magic_quotes_runtime: Off (False)
E_STRICT: 0
E_DEPRECATED: 0
memory_limit: 128M
max_execution_time: 120
output_buffering: 4096
safe_mode: Off (False)
file_uploads: On (True)
post_max_size: 8M
upload_max_filesize: 32M
session_save_path: /tmp (1777)
session_use_cookies: On (True)
xml_function: On (True)
xmlreader_class: On (True)

Server Information:
Server Api: cgi-fcgi
Server Db Type: MySQL (mysqli)
Server Db Version: 5.1.70
Server Db Grants: Found a "GRANT ALL" statement that appears to be suitable

----------------------------------------------

Paul, many thanks for posting your test results and for confirming the bug.

Haven't heard back from anyone on the CMSMS Team in a long while regarding this issue.

Can someone from the CMSMS Team please provide an update on this.

If you think this is a bug, please post a bugreport with information how to reproduce it in the Forge.

Thanks, Rolf

Just checked and a bug report already exists in the Forge for this very issue:
[#8694] Overwriting existing file mixes contents - reported on Nov 30, 2012 by Jonathan Schmid.

Cool, will look into it

The original reporter (Jonathan Schmid), provided a method by which to mask the bug by negating the "if" condition. A better approach would be to revisit the code to see why that check is needed in the first place. Also there is a $tmp variable being set but not used anywhere else.

However, I also realize that this module is being completely revamped for CMSMS 2, so perhaps only a quick fix is justified...?

-S

I have mentioned this thread on the bug report at
http://dev.cmsmadesimple.org/bug/view/8694