OK, here is the situation... I have a SOHO LAN with a variety of systems connected; but only three of them are of interest to this discussion:

-- A general-purpose fileserver running Debian Stable ("Wheezy") with all current updates (Debian version 7.8; kernel release 3.2.0-4-686-pae; kernel version 3.2.65-1+deb7u1). It does NOT run a GUI of any type, and is primarily administered from one of the local workstations via an SSH console connection (or, occasionally, via Webmin). This server also runs Samba version 3.6.6 to support SMB-based file sharing across the LAN. Samba runs in "Share Level" security mode to aid simplicity of access from whatever workstation I happen to be using at that moment.

-- A general-purpose workstation, also running Debian Stable ("Wheezy") with all current updates (Debian version 7.8; kernel release 3.2.0-4-amd64; kernel version 3.2.65-1). This workstation runs KDE version 4.8.4, which includes Dolphin version 2.0 (marked a using KDE Development Platform 4.8.4).

-- A general-purpose workstation running Kubuntu 14.04.2 LTS with all current updates (kernel version 3.13.0-45-generic). This workstation runs KDE version 4.13.3, which includes Dolphin version 4.13.3.

User accounts & passwords are identical across the LAN (i.e., I have the same user name & PW on all machines).

Now for the problem:

When using Dolphin on the first workstation (running the slightly older version of KDE under straight Debian) to copy or move files to or from the file server, the time & date stamps on all files remains intact. Any newly created folders (such as sub-folders of the folder you're moving/copying) are stamped with the current date & time; but the files themselves are reliably unscathed. All well and good. I can live with that.

HOWEVER, when performing exactly the same operations from the second workstation (running the newer version of KDE under Kubuntu), the date/time-stamps are almost always mangled in the process. I say "almost always" because the mangling is INCONSISTENT: When moving/copying files from the workstation to the server, all folders AND all the files become stamped with the current date/time, every time (or at least as close to every time as I've been able to discern). BUT... When moving/copying files from the server to the workstation, it becomes a krap-shoot: Some files will still have their original date/time-stamps, while others will be stamped with the current date/time -- and there's no telling which (or how many) will be which.

As you might imagine, this makes routine "housekeeping" chores a real nightmare, as I can no longer count on the date/time-stamps to determine which version of a file is really the newest, or how long it has been since a given file has been updated.

At first, I assumed this must be due to some sort of settings discrepancy between the two workstations. But I've been through every even semi-pertinent settings screen I can find on both systems, to no avail.

I then figured it must be the result of some sort of deliberate running change in Dolphin's behavior. But the inconsistency shown on the Server --> Workstation transfers argues against this.

Hence it seems more like some sort of a communications issue between the the server and this particular workstation. Yet, I can reliably transfer both large files and large batches of files with bit-for-bit accuracy, save for the date/time-stamp issue; so I don't think it is something as simple as a flaky LAN card/cable/etc..

In any event, I need a solution. Having my date/time-stamps changed every time I move a file from here to there is simply untenable, and effectively makes those date/time-stamps useless.

wild shot: do you copy via kio-file or kio-smb (or different on each machine)?
kio-file would be file:// on an smbmount (shows up in /etc/mtab) while kio-smb would be smb:// on the remote share "directly"

luebking wrote:wild shot: do you copy via kio-file or kio-smb (or different on each machine)?
kio-file would be file:// on an smbmount (shows up in /etc/mtab) while kio-smb would be smb:// on the remote share "directly"

The latter.

Notably, I also posted essentially this same question on another forum (Kubuntu Forums), where someone suggested that it is SMB "kio slave" itself which is the culprit. I've since tried accessing the server (from the "problem" workstation) via the sFTP protocol, rather than SMB-- and that seems to work!

I'm still looking for the appropriate place to file a bug report against whichever file/package supplies this "kio slave" in Kubuntu.

This might be due to a change of the file owner (UID) on copy (check both clients for that), which would likely not occur when "really" mounting (as root) the share via mount.cifs (ie. an /etc/fstab entry)

I don't know whether, in case, this would be a bug or a system restriction (at least NFS has opt-out security restrictions when the client isn't on a port < 1024, which can only be opened by root)

=> http://bugs.kde.org, product "kio", component: "smb"

luebking wrote:This might be due to a change of the file owner (UID) on copy (check both clients for that), which would likely not occur when "really" mounting (as root) the share via mount.cifs (ie. an /etc/fstab entry)

Well, since I don't "mount" the server volume in either case (the one that works right, or the one which doesn't), I seriously doubt that's relevant. Besides, I really think we've narrowed it down to a bug in Kubuntu/Ubuntu-specific versions of "kde-runtime". I'm in the process of writing up a formal bug report now, and will hopefully post it sometime later today or tomorrow.

=> http://bugs.kde.org, product "kio", component: "smb"

Thanks. That's one of the places I'll report the bug, just in case it really did originate at KDE (which I tend to doubt, but...). I think I need to create a Launchpad account to report it against Kubuntu/Ubuntu; but I am unclear on whether that one report would cover both variants, since Kubuntu is no longer an "official" Canonical product (I still think the bug originated there, as I believe that both variants use the same underlying KIO Slaves).