Announcement

**TWPonKubuntu** · Feb 19, 2015, 12:46 PM

Two things come to mind:
1) Difference in clock settings between workstation and server(s).
2) Dolphin configuration. disclaimer: I can't find anything on my Dolphin settings that would effect timestamps, but there may be something I am not aware of for additional settings.

**Weary1** · Feb 19, 2015, 02:09 PM

Originally posted by TWPonKubuntu View Post

Two things come to mind:

First, thanks for responding.

1) Difference in clock settings between workstation and server(s).

All the systems in question run "chrony" (http://chrony.tuxfamily.org/manual.html) to automatically sync their clocks to within microseconds (milliseconds at worst) of a Tier 1 NTP server.

Besides, we're not talking about small differences here. The files being moved/copied can have original date/timestamps which are months or years old. But upon being copied or moved (by the "problem" system), the new copies are suddenly dated "NOW". Since the files themselves did NOT change, this shouldn't happen.

2) Dolphin configuration. disclaimer: I can't find anything on my Dolphin settings that would effect timestamps, but there may be something I am not aware of for additional settings.

I looked high and low too, and also came up empty. Hence my query here.

**kubicle** · Feb 19, 2015, 02:37 PM

It isn't dolphin or it's settings (or at least it shouldn't be, kde-cp and kde-mv should preserve mtimes of files...similar to cp -a)

But if you're using dolphin to copy files between separate machines, you're using kio slaves (sftp://, ftp:// webdav(s):// etc.) and these have their own implementations of the actual copy operations, and at least some of them have buggy histories in keeping mtimes.

Whether mtimes are kept can basically depend on which kio slave you use, version of the kio slave and even if you are copying from remote to local or local to remote.

One of the reasons I generally prefer tools like rsync to copy/move files (en masse) between machines.

Which kio slave are you using?

**Weary1** · Feb 19, 2015, 02:58 PM

Originally posted by kubicle View Post

It isn't dolphin or it's settings (or at least it shouldn't be, kde-cp and kde-mv should preserve mtimes of files...similar to cp -a)

But if you're using dolphin to copy files between separate machines, you're using kio slaves (sftp://, ftp:// webdav(s):// etc.) and these have their own implementations of the actual copy operations, and at least some of them have buggy histories in keeping mtimes.

Whether mtimes are kept can basically depend on which kio slave you use, version of the kio slave and even if you are copying from remote to local or local to remote.

All that sounds reasonable, and probably on-point. As I mentioned in the original post, even when using the same (problematic) workstation, WS --> Server copy/move operations act differently from Server --> WS copy/move operations; and the latter is additionally inconsistent in whether or not it preserves the date/time-stamps (the former mangles them every time).

One of the reasons I generally prefer tools like rsync to copy/move files (en masse) between machines.

In order to make that an even marginally usable approach, I'd need to study up a LOT more on rsync. (That's something I need to do for other reasons; but that's a project for another day.) For now, I really need to get the "Drag & Drop" approach to work correctly.

Which kio slave are you using?

No idea. I've never heard the terms "kio" or "kio slave" before. If you can tell me how to determine that, I'll gladly do so and post the answer.

FWIW (and in case it's relevant), the "location Bar" in the "other" pane or window in Dolphin (i.e., the one showing the Server's filesystem, as opposed to the local filesystem) uses a URI which starts with "smb://".

Thanks for your help.

**kubicle** · Feb 19, 2015, 03:35 PM

Originally posted by Weary1 View Post

No idea. I've never heard the terms "kio" or "kio slave" before. If you can tell me how to determine that, I'll gladly do so and post the answer.

FWIW (and in case it's relevant), the "location Bar" in the "other" pane or window in Dolphin (i.e., the one showing the Server's filesystem, as opposed to the local filesystem) uses a URI which starts with "smb://".

You figured it out, that "smb://" means you're using the samba kio slave to transfer files. Unfortunately I don't use samba so I can't really troubleshoot it (or just confirm the problem) without some extra work.

But if you are keen to get drag-and-drop working, aren't dead set on using the samba slave for it and have an ssh connection already working between the machines...you can try using the sftp:// kio-slave instead (on my end at least, it keeps the mtimes intact). There are a few ways to go about testing the sftp kio slave in dolphin:

1. Just type the sftp address in your remote pane address bar in dolphin, the address looks like:

Code:

sftp://user@host:port/path/to/directory/on/the/remotehost
where "user@host:port" are the same you use for your ssh connections 
(for example: sftp://weary@192.168.1.100:22/home/weary)

2. In Dolphin's "Places", choose Network>Add Network Folder>ssh and fill in details

**Weary1** · Feb 19, 2015, 04:05 PM

Originally posted by kubicle View Post

You figured it out, that "smb://" means you're using the samba kio slave to transfer files. Unfortunately I don't use samba so I can't really troubleshoot it (or just confirm the problem) without some extra work.

But if you are keen to get drag-and-drop working, aren't dead set on using the samba slave for it and have an ssh connection already working between the machines...you can try using the sftp:// kio-slave instead (on my end at least, it keeps the mtimes intact).

OK, we're making progress!

There are a few ways to go about testing the sftp kio slave in dolphin:

1. Just type the sftp address in your remote pane address bar in dolphin, the address looks like:

Code:

sftp://user@host:port/path/to/directory/on/the/remotehost
where "user@host:port" are the same you use for your ssh connections
(for example: sftp://weary@192.168.1.100:22/home/weary)

2. In Dolphin's "Places", choose Network>Add Network Folder>ssh and fill in details

At least based on some (very) quick preliminary tests, your "Method #2" seems to be doing the trick. (I chose it first based on the hope that it would automagically assume some of the details that I would otherwise have to guess at.) I can now copy files & folders full of files back and forth without screwing up the date/time-stamps. It nags me for my username & PW when I first access the server this way; but that's not a big deal (as long as it doesn't *incessantly* nag me for it).

I'll keep testing this until I'm convinced it's reliable; but as of the moment, I'm quite optimistic about it.

Now... On a semi-related note: Since it would now appear that the root of the problem is actually a malfunction in what you called the "samba kio slave" on this one system only (remember, the straight-Debian system works fine), that sounds like a candidate for a bug report. I have never submitted such, and have no idea where/how/etc. to do so. Any pointers would be appreciated.

And of course: THANK YOU!

**kubicle** · Feb 20, 2015, 01:00 AM

Originally posted by Weary1 View Post

At least based on some (very) quick preliminary tests, your "Method #2" seems to be doing the trick. (I chose it first based on the hope that it would automagically assume some of the details that I would otherwise have to guess at.) I can now copy files & folders full of files back and forth without screwing up the date/time-stamps. It nags me for my username & PW when I first access the server this way; but that's not a big deal (as long as it doesn't *incessantly* nag me for it).

If you have kwallet enabled, you should be able to save the password in kwallet. Or you can set up hostkey authentication for your ssh connections, in which case you don't need password authentication.

Originally posted by Weary1 View Post

I'll keep testing this until I'm convinced it's reliable; but as of the moment, I'm quite optimistic about it.

There are some added benefits to using sftp. As it uses ssh, the transfers are securely encrypted, so it's safe to use over wireless connections and even over the internet.

Originally posted by Weary1 View Post

Now... On a semi-related note: Since it would now appear that the root of the problem is actually a malfunction in what you called the "samba kio slave" on this one system only (remember, the straight-Debian system works fine), that sounds like a candidate for a bug report. I have never submitted such, and have no idea where/how/etc. to do so. Any pointers would be appreciated.

This looks like a good canditate for a bug report. However, there are usually a few things I personally like to do first before submitting a bug report (the more info you can gather for the report, the more likely it is to be resolved):
1. Is there a bug report already? (you can search bugs.kde.org and launchpad for kubuntu bugs)
2. Can anyone else confirm the issue? (I'm sure these forums have a few samba users)
3. Is it already fixed in latest upstream versions?
4. Is the issue specific to kubuntu? Or does it affect other distributions with same software versions?

How much info you want to gather is of course totally up to you, sometimes just a simple report describing the issue and the software versions you are using is quite enough.

**Weary1** · Feb 20, 2015, 01:17 PM

Originally posted by kubicle View Post

If you have kwallet enabled, you should be able to save the password in kwallet. Or you can set up hostkey authentication for your ssh connections, in which case you don't need password authentication.

Neither are in use at the moment; and as long as the "nagging" doesn't get too intrusive, I'll probably leave it that way.

One thing I forgot to ask: Will this new "Place" (server via sFTP) in Dolphin be persistent, now that I've set it up? So far, I've tried opening & closing new Dolphin instances/windows; and indeed, it does "automagically" appear in those new windows. But I've yet to try shutting down Dolphin entirely; and for unrelated reasons, I don't want to re-boot this system right now to test if it's *really* permanent.

There are some added benefits to using sftp. As it uses ssh, the transfers are securely encrypted, so it's safe to use over wireless connections and even over the internet.

Good to know.

OTOH, there's no WiFi here, either, and very little reason to add it. If I ever do implement WiFi, it will be on its own dedicated (and very tightly locked-down) subnet, with at most "pinhole" access to the rest of the LAN.

On the third hand, at some point in the future, I can see myself implementing a semi-permanent VPN tunnel between my shore home to here. While the VPN implementation SHOULD provide all the necessary encryption itself, I suppose yet-another-layer couldn't hurt.

This looks like a good canditate for a bug report. However, there are usually a few things I personally like to do first before submitting a bug report (the more info you can gather for the report, the more likely it is to be resolved):
1. Is there a bug report already? (you can search bugs.kde.org and launchpad for kubuntu bugs)
2. Can anyone else confirm the issue? (I'm sure these forums have a few samba users)
3. Is it already fixed in latest upstream versions?
4. Is the issue specific to kubuntu? Or does it affect other distributions with same software versions?

At this point, based on everything I've learned so far, I'm willing to wager that this "bug" is at least Ubuntu-specific, if (probably) not Kubuntu-specific.

1. - As noted previously, the straight-Debian/KDE workstation does NOT exhibit the bug.

2. - Canonical has a well-known penchant for "tweaking" standard/upstream packages to suit their own tastes & purposes. So if whichever package provides the "samba kio slave" function is indeed a (k)ubuntu-specific version, that would be a very plausible "entry point" for the bug.

So all in all, I suspect that "bugs.kde.org " is NOT the right place to report this.

In an effort to determine which program/package might actually be the culprit, I did a search on "SMB" from within Synaptic. That produced several dozen hits; but (thankfully) most of them are NOT installed on this system. Of the ones left standing, there appears to be a related group of packages centered around Samba (including, among others, "samba-common", "samba-common-bin", "samba-libs", "libsmbclient", etc.), all of which carry the same Ubuntu-specific version number (2.4.1.6+dfsg-1ubuntu2.14.04.5). Is this where you would expect to find the code which provides the "samba kio slave" function?

Next I tried searching https://bugs.launchpad.net/ubuntu. After a few false starts, I came across this:

https://bugs.launchpad.net/ubuntu/+s...mba/+bug/73452

It is perhaps not EXACTLY the same thing, as the original reporter (and at least one or two of the commenters) was using a Windows-based server, as opposed to a Linux server running Samba. But the symptoms match almost exactly -- which is just what you'd expect if the problem is actually in the SMB client, rather than at the server. So I strongly suspect it is on-point.

Unfortunately, it would appear that this bug report has been languishing since 2006, despite being "re-confirmed" (so to speak) in 2007 and 2009. Yet, the bug is still marked "Low Importance" and "Unassigned". That strikes me as exceedingly odd, given how fundamental a function reliable error-free file transfers are, and how much of a PITA this particular problem can be. Why is this not being given more attention, and what can be done to give the powers that be a swift kick in the you-know-what?

How much info you want to gather is of course totally up to you, sometimes just a simple report describing the issue and the software versions you are using is quite enough.

So... Do I simply tack on yet another comment to that 8+ year old bug report? That approach hasn't seemed to get much action thus far.

**kubicle** · Feb 20, 2015, 02:31 PM

Originally posted by Weary1 View Post

Neither are in use at the moment; and as long as the "nagging" doesn't get too intrusive, I'll probably leave it that way.

Entirely up to you, of course

Originally posted by Weary1 View Post

One thing I forgot to ask: Will this new "Place" (server via sFTP) in Dolphin be persistent, now that I've set it up? So far, I've tried opening & closing new Dolphin instances/windows; and indeed, it does "automagically" appear in those new windows. But I've yet to try shutting down Dolphin entirely; and for unrelated reasons, I don't want to re-boot this system right now to test if it's *really* permanent.

If you had the setting "Create a shortcut for this network folder" checked when you created it, it'll stay permanently in the "network" folder (unless you delete it, naturally)...you can also add the folder to your "places" for even quicker access.

Originally posted by Weary1 View Post

OTOH, there's no WiFi here, either, and very little reason to add it. If I ever do implement WiFi, it will be on its own dedicated (and very tightly locked-down) subnet, with at most "pinhole" access to the rest of the LAN.

On the third hand, at some point in the future, I can see myself implementing a semi-permanent VPN tunnel between my shore home to here. While the VPN implementation SHOULD provide all the necessary encryption itself, I suppose yet-another-layer couldn't hurt.

No problem. Encrypted transfer is often not necessary on your own LAN (like you said, doesn't really hurt either), just thought I'd mention it in case you wish to transfer over insecure networks.

Originally posted by Weary1 View Post

In an effort to determine which program/package might actually be the culprit, I did a search on "SMB" from within Synaptic. That produced several dozen hits; but (thankfully) most of them are NOT installed on this system. Of the ones left standing, there appears to be a related group of packages centered around Samba (including, among others, "samba-common", "samba-common-bin", "samba-libs", "libsmbclient", etc.), all of which carry the same Ubuntu-specific version number (2.4.1.6+dfsg-1ubuntu2.14.04.5). Is this where you would expect to find the code which provides the "samba kio slave" function?

The kio slaves are kde software, in kf5 (which is what I'm running) the kio slave for samba is in the package "kio-extras". In KDE 4.x, it's in the package "kde-runtime" (/usr/lib/kde4/kio_smb.so).

**Weary1** · Feb 20, 2015, 03:56 PM

Originally posted by kubicle View Post

If you had the setting "Create a shortcut for this network folder" checked when you created it, it'll stay permanently in the "network" folder (unless you delete it, naturally)...you can also add the folder to your "places" for even quicker access.

I don't recall seeing any such checkbox when I created the item under "Places". There was one labeled "Only show when using this application (Dolphin)", which I left UN-checked. We'll see, I suppose.

No problem. Encrypted transfer is often not necessary on your own LAN (like you said, doesn't really hurt either), just thought I'd mention it in case you wish to transfer over insecure networks.

Fair enough. Who knows... It may come in handy at some point.

The kio slaves are kde software, in kf5 (which is what I'm running) the kio slave for samba is in the package "kio-extras". In KDE 4.x, it's in the package "kde-runtime" (/usr/lib/kde4/kio_smb.so).

Hmmm... OK, that surprises me a little, in light of how similar that previously cited Samba-specific bug seems to what I experienced. OTOH, perhaps one of the reasons the bug has gone so long without being addressed is that everyone is looking for it in the wrong place? That seems a stretch, but...?

In any event, my theory about this problem being Ubuntu-specific seems to hold anyway. The version of "kde-runtime" on the straight-Debian/KDE system is "4:4.8.4-2". On the Kubuntu system, it is "4:4.13.3-0ubuntu0.2" -- which is again a Ubuntu-specific version. So while the "kio slaves" may have originated at KDE.org, I still strongly suspect the bug itself crept in at Ubuntu.

So I guess that means I should endeavor to file a new bug report, specifically against the Ubuntu version of "kde-runtime", but citing the "prior art" so to speak. I'll have to dig into that later, as I still have several other things I need to spend time on this afternoon.

(BTW... I gather that "kio-extras" will be at least partially replacing "kde-runtime" in KDE5? While I highly doubt that one specific change will be of any practical consequence to me, I sure hope KDE5 itself is still a long ways down the road -- I've barely come to grips with KDE4 (and all the "change for the sake of change" it wrought) after successfully avoiding it for as long as I could.)

**SteveRiley** · Feb 20, 2015, 05:38 PM

Originally posted by Weary1 View Post

In any event, my theory about this problem being Ubuntu-specific seems to hold anyway. The version of "kde-runtime" on the straight-Debian/KDE system is "4:4.8.4-2". On the Kubuntu system, it is "4:4.13.3-0ubuntu0.2" -- which is again a Ubuntu-specific version. So while the "kio slaves" may have originated at KDE.org, I still strongly suspect the bug itself crept in at Ubuntu.

KIO slaves have been part of KDE for a long time. Debian stable's KDE is currently at 4.8.4 (which is, alas, rather old) while Ubuntu's is 4.13.3 in the release you've installed. More accurately, it's Kubuntu's version; in the vast majority of cases, the Kubuntu team packages up KDE's software largely unchanged. Unlike what you wrote in your post #9, Canonical has no involvement in Kubuntu packaging and doesn't touch the bits at all.

Originally posted by Weary1 View Post

So I guess that means I should endeavor to file a new bug report, specifically against the Ubuntu version of "kde-runtime", but citing the "prior art" so to speak. I'll have to dig into that later, as I still have several other things I need to spend time on this afternoon.

Yes, that would be correct.

Originally posted by Weary1 View Post

(BTW... I gather that "kio-extras" will be at least partially replacing "kde-runtime" in KDE5? While I highly doubt that one specific change will be of any practical consequence to me, I sure hope KDE5 itself is still a long ways down the road -- I've barely come to grips with KDE4 (and all the "change for the sake of change" it wrought) after successfully avoiding it for as long as I could.)

KDE 5 is an important evolution of the KDE SC. Frameworks 5 breaks the elements of KDE Platform 4 into independent cross-platform modules that can be more easily reused by other Qt-based applications. Plasma 5 is the first implementation of Plasma written entirely in QtQuick and takes advantage of hardware accelerated GPUs and prepares the way for Wayland.

**kubicle** · Feb 21, 2015, 02:58 AM

Originally posted by Weary1 View Post

I don't recall seeing any such checkbox when I created the item under "Places". There was one labeled "Only show when using this application (Dolphin)", which I left UN-checked. We'll see, I suppose.

I thought you mentioned that you created the connection with Places>Network>AddNetworkFolder? The setting to "create a shortcut for the connection" is in that dialog.
If you added it manually to places your link will stick as well.

Steve already touched the rest, I'll add my 2 cents:
1. While I cannot be certain the bug isn't ubuntu specific, the most glaring diff between your debian and kubuntu machines are their KDE versions. So my first guess would be that the bug is in the samba kio slave in 4.13.x and not in 4.8.x. This is just a guess of course.

2. KDE5 will eventually replace KDE4 (In Kubuntu, the process starts with the next release, 15.04). You don't have to jump in just yet of course (you can stick with kubuntu 14.04 LTS with KDE4 until 2019 as you wait for KDE5 to mature).

**Weary1** · Feb 21, 2015, 03:10 PM

Originally posted by SteveRiley View Post

KIO slaves have been part of KDE for a long time. Debian stable's KDE is currently at 4.8.4 (which is, alas, rather old) while Ubuntu's is 4.13.3 in the release you've installed.

As you probably know, Debian Stable is known for being "slow" (by some folks' standards) to adopt new versions, precisely because they go through far more (and more widespread) testing before being accepted into the "Stable" release than is the case for most distros. The "Testing" and "Unstable" releases are far more "bleeding edge"; but in most cases, that's not what you want in a production environment. This is precisely the same logic which prompted me to use v14.04.2 LTS when I decided to set up a Kubuntu system, rather than v14.10.

All that said, KDE 4.8.4 is current, at least in terms of Debian Stable, and was "new" as of the release of Debian 7.0 about a year and a half ago. So, not born yesterday; but not ancient either. And besides, I'll take "works right" over "new & snazzy" any day of the week.

More accurately, it's Kubuntu's version; in the vast majority of cases, the Kubuntu team packages up KDE's software largely unchanged. Unlike what you wrote in your post #9, Canonical has no involvement in Kubuntu packaging and doesn't touch the bits at all.

OK. I'll take your word for that. But then, why do the version numbers for the packages in question all carry "ubuntu", as opposed to "kubuntu" in their names? For example, "kde-runtime" is version "4:4.13.3-0ubuntu0.2"; and the various Samba-related packages ("samba-common", "samba-common-bin", "samba-libs", "libsmbclient", etc.) are all version "2.4.1.6+dfsg-1ubuntu2.14.04.5".

In the interest of completeness, I'll endeavor to file the bug report (when I finish writing it) to KDE.org as well as to bugs.launchpad.net/ubuntu. But as of the moment anyway, I'm betting that the latter is the more appropriate venue.

*** WARNING: Off-Topic Rant ***

KDE 5 is an important evolution of the KDE SC. Frameworks 5 breaks the elements of KDE Platform 4 into independent cross-platform modules that can be more easily reused by other Qt-based applications. Plasma 5 is the first implementation of Plasma written entirely in QtQuick and takes advantage of hardware accelerated GPUs and prepares the way for Wayland.

All that may well be the neatest thing since sliced bread -- to a developer. But it is essentially meaningless to the end-user. This is something I think far too often "gets lost" by folks who are too close to a project to see the bigger picture. KDE4 was a MAJOR upheaval to the entire user base, to the point that the entire "Trinity" project was born just to find an acceptable alternative. It was not until at least several "point releases" down the line that KDE4 was sufficiently "tamed" to make the transition (from KDE 3.x) tolerable. I understand that there were some major improvements "under the skin" so to speak; and arguably, some of the re-write was necessary due to historically poorly maintained/documented code issues and similar. But NONE of that is what a normal end-user sees, or cares about. And more importantly, it not what he counts on to be able to get his work done. To him, any unrequested operational change is by definition at least a PITA, and maybe an utter disaster. Understand, I'm not singling out KDE on this, but more talking in general. For example, the same situation cropped up with Mozilla Firefox when they summarily chucked virtually the entire user interface to introduce "Australis" -- which was the "last straw" for a LOT of folks (and finally drove me to Pale Moon, at least for now).

The point is, it doesn't matter if the "Shiny New Thing" is, by some measure, objectively "better" than the old one; What matters is that it is *different*; and the more it's different, the more it requires re-learning, and re-evaluation of working procedures, and all sorts of other follow-on effects. That, in and of itself, is ALWAYS a liability, and a larger one than (it would seem) most developers are capable of understanding or appreciating. So when "The Next New Thing" is being developed, it is VITAL that, at least from the user's perspective, it looks, feels, and works absolutely as close to the old one as possible, even if the developers HATE the old version. The "new stuff" can be configurable options or similar; but it should NEVER be forced upon the user, or even presented as the default, leaving him to wonder "Howinhell do I get it back to the way I had it?!?" as soon as the update completes.

Bottom Line: "Newer" and "Better" are NOT synonymous terms.

Well, I'll climb off the soap-box now. But is a widespread problem, which seems to be getting worse all the time.

*** End Of Rant ***

**Weary1** · Feb 21, 2015, 03:28 PM

Originally posted by kubicle View Post

I thought you mentioned that you created the connection with Places>Network>AddNetworkFolder?

Actually, it was "Places" --> "Network" --> "Add Entry..."

Steve already touched the rest, I'll add my 2 cents:
1. While I cannot be certain the bug isn't ubuntu specific, the most glaring diff between your debian and kubuntu machines are their KDE versions. So my first guess would be that the bug is in the samba kio slave in 4.13.x and not in 4.8.x. This is just a guess of course.

Obviously, I don't really know; but I'd wager against it. Given that almost precisely the same issue (which may well have also *really* been due to the KIO Slave) was reported against a Ubuntu-specific version of Samba all the way back in 2006 (cf. https://bugs.launchpad.net/ubuntu/+s...mba/+bug/73452) this bug has apparently been around since LONG before KDE4, let alone KDE 4.8.4, was released. I only just recently discovered it because I only just recently set up a system using Kubuntu.

In any event, and as I mentioned to Steve, I'll try to post the Bug Report in both places, when it's done.

2. KDE5 will eventually replace KDE4 (In Kubuntu, the process starts with the next release, 15.04). You don't have to jump in just yet of course (you can stick with kubuntu 14.04 LTS with KDE4 until 2019 as you wait for KDE5 to mature).

See my reply to Steve for some of the more general background on this. But "maturing" is, at best, only part of the issue. Just as important (if not more so) is that when KDE5 is released, it looks/feels/tastes/seems -- and especially *works* -- just like KDE4 in every way possible, at least until the user deliberately changes settings to enable the new eye candy or whatever. This would likely take a major mindset change on the part of the developers; but it's what is needed.

Announcement

Time-Stamping Weirdness

Time-Stamping Weirdness

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment