3

I have a weird problem where PHP's file_put_contents() and fwrite() (after opening file handle with fopen('filename', 'w');) functions are not truncating the target file as stated by the PHP docs for fwrite(). The file resides on a Seagate BlackArmor NAS device, which is mounted on a Linux server (Ubuntu 10.04) using CIFS, as follows:

mount -t cifs -o defaults,credentials=/etc/smbpass/demo.smbpass,uid=1005,gid=1005,dir_mode=0770,file_mod=0660 //xxx.xxx.xxx.xxx/demo/files /var/www/mysite/src/files/

Example:

Contents of myfile.txt: thisisabigfatpandaonwheelsgoingdownthestreet

Run PHP script with code: file_put_contents('myfile.txt', 'blah');

Contents of myfile.txt: blahisabigfatpandaonwheelsgoingdownthestreet

The expected contents of the file is obviously blah, but that's not the case.

Any ideas?

Johan Meiring
  • 31
  • 4
  • 1
    `file_put_contents()` does not require a file handle, and using it in conjunction with `fopen()`/`fwrite()` make no sense. Can you show your full code? Also, if you want to overwrite the file completely, you could always just [`unlink()`](http://php.net/manual/en/function.unlink.php) it before you start. – DaveRandom Aug 31 '12 at 08:35
  • My apologies, I meant that `fopen()` is only used when I tried using `fwrite()`. It wasn't used at all when trying `file_put_contents()` I considered using `unlink()` but would rather avoid it, as it would mean changing code instead of trying to solve a problem that may be OS-based. – Johan Meiring Aug 31 '12 at 08:41
  • Oh, right, no worries, maybe you should slightly rephrase the question. In that case I would say `unlink()`ing before the operation will definitely work, I would also be interested to know what the result of this code is: `$fp = fopen('myfile.txt', 'w'); ftruncate($fp, 0); rewind($fp); fwrite($fp, 'that'); fclose($fp);` – DaveRandom Aug 31 '12 at 08:43
  • Interestingly enough, `ftruncate()` and then `rewind()` had no effect, i.e. same result as before. Deleting the file with `unlink()` and then writing to it does work though. – Johan Meiring Aug 31 '12 at 08:57
  • does the same thing happen in the shell? (echo blah > myfile.txt) – msEmmaMays Aug 31 '12 at 09:00
  • yup... same thing happens in the shell. so it's obviously not a PHP-specific problem. http://svn.alfresco.com/repos/alfresco-open-mirror/alfresco/HEAD/root/modules/truncate-malformed-xml/README.txt seems to point the finger at SMBFS vs CIFS, but I am in fact using CIFS, so I'm confused :S – Johan Meiring Aug 31 '12 at 09:03
  • @JohanMeiring M$ protocol strikes again. Workaround is to `unlink()`, the real fix for this problem has now become a question for [SuperUser](http://superuser.com/). – DaveRandom Aug 31 '12 at 09:18
  • Ok, thanks Dave. I'll post my question there as well and use unlink() in the meanwhile. – Johan Meiring Aug 31 '12 at 09:33

2 Answers2

2

I had the exact same symptoms on a samba setup of my own (Debian 6 x64 with samba 3.5.6.). I finally narrowed it down to the following option causing the exact same behaviour:

large readwrite = no

When set to yes instead (or removed, as yes is the default setting), the issues were gone.

Filed bug reports against Debain and upstream Samba:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=699461
https://bugzilla.samba.org/show_bug.cgi?id=9622

toubsen
  • 189
  • 12
1

the file is not world readable/writable because of your mount flags

mount -t cifs -o defaults,credentials=/etc/smbpass/demo.smbpass,uid=1005,gid=1005,dir_mode=0770,file_mod=0660 //xxx.xxx.xxx.xxx/demo/files /var/www/mysite/src/files/

If you are running this through a web server it won't have permission to access the file because it runs as a different user. You can use is_writable('myfile.txt') to tell if that's the case.

msEmmaMays
  • 1,073
  • 7
  • 7
  • `it runs as a different user` - not necessarily. Also, he has set the write bit on group, so if the web server user is in the owner group it will still work. I suspect this is a red herring because if you look carefully (took me a while to see it properly) the write operation is succeeding, the first 4 bytes are altered, but the remaining bytes are not truncated. Not a completely stupid/wrong answer though, so I won't downvote. – DaveRandom Aug 31 '12 at 08:48
  • I tried changing the permissions to 0777 and 0666 respectively, and that had no effect. The file definitely is writable in both cases but it's not being truncated properly. – Johan Meiring Aug 31 '12 at 08:50
  • @DaveRandom is right - I didn't notice the slight change in the line (this/that) indicating the file was actually being written. – msEmmaMays Aug 31 '12 at 08:52
  • I've altered the test case, hope it's more visible now ;) – Johan Meiring Aug 31 '12 at 08:56