[SOLVED] PCLinuxOS changes date stamp on copied files, but Mint Debian does not

[whs001]

To save time for most readers, I'll state my problem very briefly first, and then give the full background:  When I copy files from one disk drive to another using PCLinuxOS, the copied files get stamped with the current date; when I do the exact same thing using Linux Mint Debian edition, the copied files retain the date of the original file.  I want my copied files to retain their original date in PCLinuxOS, and I have no idea why the two versions of Linux are giving me different results.  So, of course, I have no idea how to change what is happening in PCLinuxOS.

I have three partitions on my hard drive, Windows Vista, which came installed; Linux Mint Debian Edition, which I have had on the machine for about six months (replacing Linux Mint based on U*u, which I had installed when the machine was new); and PCLinuxOS, which I installed about two months ago and have been using most of the time since then.  I have recently noticed that PCLinuxOS is changing the date stamp on files that I save on the Windows Vista partition or on external media, which is severely messing up my idiosyncratic system of file organization.  I don't have the same problem with Mint Debian.

This problem occurs with identical end-user programs on PCLinuxOS and on Mint Debian:  On both systems, I am running LXDE on OpenBox, and I am using GNOME Commander to run folder comparisons and to select the files to be copied.  In PCLinuxOS, when I copy a file from one folder to another within the PCLinuxOS partition, the file retains its date stamp, but when I copy it to the Windows Vista partition or to a USB drive, the copy gets a current date stamp.  In Mint Debian, copied files keep their original date stamp whether I copy them from one place to another within the Mint Debian partition, or copy them to the Windows Vista partition or to a USB drive.  What the heck is going on?

I can't find a setting in GNOME Commander to choose to give copied files a current date stamp or to retain their original date stamp, and I certainly didn't select to do it one way in Mint Debian and the opposite way in PCLinuxOS.  And I can't imagine that this is a difference between one installation of LXDE and another.  There must be something set within the Linux operating system that I know nothing about that is creating the difference, but I have absolutely no idea what or where it is, and after a few hours of trying to find help on Google, I've given up.

Please don't respond with advice to use "cp -preserve" (cp -p) or other command line tools; this is PCLinuxOS I'm asking about, and it's supposed to be user-friendly rather than dominated by guys who want to show off their command line skills like they do on the U*u forums.  I use the command line almost every day, but I have a number of reasons for needing a graphical program like GNOME Commander that can show me which files are the same and which files are different in two folders, and then let me pick which ones to copy or delete.

Thanks.

[JohnW_57]

It does not my system, just copied a file from home map to a external usb drive and the timestamps is still same on both files.
Used: PCLinuxOS KDE4 version and Dolphin filemanager.

JohnW

[Just18]

What file systems are in play here?

Obviously Windows is using one of the MS filesystems, but what fs is on the USB drive?

Just wondering if this is FS related in any way ......

[whs001]

That's an excellent question, Just 18.  Thanks.  As a test, I just copied a file from the PCLinuxOS partition to the Mint Debian partition and the date did not change; to make sure I was getting my story straight, I then copied the same file from the PCLinuxOS partition to the Windows partition, and the date did change.  Also, my USB drives are in FAT32 format.  So it appears that the Windows file system might be the culprit, except that I haven't had the same problem when copying from the Mint Debian partition to the Windows partition.  I did that for months and never noticed that my file dates were getting screwed up. 

Putting the two behaviors together, it seems as though there is something different in how PCLinuxOS and Mint Debian are sending files to a Windows file system, so that NTFS and FAT32 recognize and keep the file date from Mint Debian but not from PCLinuxOS.

On both systems, I have the Windows partition mounted at /Vista.  One difference I can think of that might be relevant is that in Mint Debian I had also set up a Windows SMB share but (much to my annoyance with myself) I couldn't readily get it set up in PCLinuxOS.  But then I got a Pogoplug and thought that Internet transfers would be adequate without SMB, so I haven't gotten back to that issue.  Could there be a difference because I have a Windows share in Mint Debian, even though I am using GNOME Commander to copy the files to local, mounted drive?

Thanks again.

[Just18]

I would be inclined to check the mounting parameters of the partitions in question.

I have only one small FAT partition here and do not see any change in date when copying to it. (I only tried a couple of files)

I do not have a FSTAB entry for that partition, so it is being mounted by hal/udev/whatever.

Neither do I have SMB/SAMBA here as I have no need of that either, so cannot check any of that.

[whs001]

Thanks again for following up on my problem.  In PCLinuxOS, the fstab entry for the Windows Vista partition is
UUID=01CC7BB1E4913090 /Vista ntfs-3g defaults,umask=000 0 0
none /proc proc defaults 0 0

In Mint Debian, it's:
UUID=01CC7BB1E4913090   /vista   ntfs   rw,errors=remount-ro   0   0

I don't claim to understand the /proc line, which is in the PCLinuxOS file and not in the Mint Debian file.  In my limited understanding, I don't see a relevant difference between the two files. 

[Just18]

Thanks again for following up on my problem.  In PCLinuxOS, the fstab entry for the Windows Vista partition is
UUID=01CC7BB1E4913090 /Vista ntfs-3g defaults,umask=000 0 0
none /proc proc defaults 0 0

In Mint Debian, it's:
UUID=01CC7BB1E4913090   /vista   ntfs   rw,errors=remount-ro   0   0

I don't claim to understand the /proc line, which is in the PCLinuxOS file and not in the Mint Debian file.  In my limited understanding, I don't see a relevant difference between the two files. 

I don't know what the default mounting parameters are .....  but there may be something there that causes the difference .....

defaults,umask=000

rw,errors=remount-ro

Maybe someone with more knowledge of this could comment.

You could, if you wished to test, comment out the existing line in PCLOS fstab, and create a new one with the same mount options as used by Mint.
That should let you know if the difference is in those mount options.

regards

[whs001]

Thanks, Just18.  That was an excellent suggestion and, with some trial and error, the problem appears to be fixed.

Simply inserting the fstab line from Mint Debian and commenting out the two that were in PCLOS did not work - the Windows Vista partition didn't mount on reboot.  By process of elimination, I decided that the partition wasn't mounting because PCLOS requires "ntfs-3g" and the simple "ntfs" that is used in Mint Debian will not work (even though some people say that when ntfs-3g is installed, "ntfs" is still recognized as an alias for it; but apparently it isn't in PCLOS).

Also, leaving in or removing "none /proc proc defaults" did not appear to make any difference with my date stamp problem, and in fact I have not observed that it makes any difference at all.

The date stamp problem was corrected by removing "umask=000" so that I only have "defaults."  I don't understand why, since as an ordinary user I could read and write files with or without umask; the difference caused by umask was that the files written by an ordinary user or by root would not keep their date stamp when the umask parameter was there.  My understanding is that umask controls which users can read, write, and execut files - but for me it seems to control the date stamp.

So this is what I now have in fstab:
UUID=01CC7BB1E4913090 /Vista ntfs-3g defaults 0 0
none /proc proc defaults 0 0

Well, I don't understand why this is a fix, but thanks again for leading me to it.

[Just18]

Glad you got it sorted        please mark the thread as [SOLVED] so others might find the answer.

regards