Hi all,

I have been struggling to set up a chat room server on the ISP's server that I use. Have succeeded now, but during the many failed attempts, it transpired that downloading the PHP scripts to my Windows partition, and then Ftping them up to the server caused lots of corruption within a lot of the php files. Only found out by chance really as it was the only reason I could think of that was causing so many PHP scripts to fail with consistent errors. At first I though it may have been gFtp causing it, but previous uploads have been fine.
Anyway, I downloaded the PHP script I wanted to use for a chat room, saving to my Linux partition, Ftp'd them to the ISP and it worked first time.
Now bothered as I have loads of downloaded programs of one way, shape or form saved in a Windows partition, including loads from SBOPKG, and loads of self compiled stuff.
So finally to the question then, just how corrupt might these programs be, and if they are does it mean downloading and compiling them all again, or is there a way to repair the damage?

Cheers

It's just a guess, but cannot the reason be that ftp is trying to automatically convert the newlines between windows/unix formats? Does the same happen if you download the files as binary?

I suppose that might be possible. I have checked some of the files on the Windows partition, and there is definitely a suspicion of corruption in them. Looks like I'm going back to my Linux partition in future.

The reason could be that the last time you used Windows you hibernated it. Windows keeps a in memory some parts of the state of the filesystem, diretories, open files, etc. If you boot Linux and write on that filesystem and then reboot with Windows, the state of the filesyste will be corrupted.

This could happen in the other way, you hibernate on Linux and after that you boot with Windows and write on the partition.

The solution is never to use hibernation if you are rebooting with a different OS.

Haven't used Windows for about 6 months, and never hibernated it. Just happen to have a windows partition as the laptop has 2 drives and never got around to doing anything with the second one except use it to store downloads on, hence the use of that particular partition type.

What FS do you have on your file partition? I don't think FS kernel driver corrupts any data, but for just in case. Only source and software which is created those scripts can be guilty.
Can you describe what so suspicious you saw?
Line ending style doesn't influence work of PHP.(it was long time ago and it is so now I hope).

This should not be a problem, Windows stores the system state in C:\Hiberfil.sys and only if this file is modified would anything go wrong.

Actually earlier version of the ntfs-3g driver wouldn't even mount a windows drive if it were hibernated due to corruption.

But we don't know what version of Slack he's using. We don't know if he's using ntfs-3g or just ntfs support.

There's simply not enough info to know why he has corruption.

But I can confirm that *yes* indeed you can write to a hibernated winxp machine, and have data corruption with ntfs-3g with a version released as little as a year ago in my experience.

There is not even enough info to know THAT he has corruption. He just has a suspicion. I mean, how hard can it be to compare three version of the same file and ascertain precisely which ones are different???

If you don't know with which file to start, start by fingerprinting whole directories using md5sum.

NTFS is a proprietary filesystem.

While support for it has come a long way over the past few years, I would try to avoid writing to it from within Linux if you need the result to be 100% free of corruption.

FAT is a better option if you want to be able to write to it from Linux, but I don't think Windows provides this option any more.

so far, i've been writing and copying data from NTFS and no problem at all using ntfs-3g

Me too, but I wouldn't bet the farm on it.

The specifications of NTFS are closed, so all development in this area is the result of 'reverse-engineering' and figuring out what works by trial and error. The results are pretty good, but nowhere near as safe (from a mission-critical standpoint) as a native Linux filesystem.