After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 584859 - SMB/CIFS path is incorrectly shortened
SMB/CIFS path is incorrectly shortened
Product: gnome-commander
Classification: Other
Component: networking
Other Linux
: Normal normal
: 2.0
Assigned To: GNOME Commander maintainer(s)
Depends on: 589069
Reported: 2009-06-04 19:44 UTC by Christoph Franzen
Modified: 2018-08-03 17:55 UTC
See Also:
GNOME target: ---
GNOME version: ---

Description Christoph Franzen 2009-06-04 19:44:22 UTC
Please describe the problem:
The server name part of the SMB path is left off when you copy or move files to a share.

Steps to reproduce:
1. Go to /LOCALPATH in one pane, and to //SERVERNAME/SHARENAME/DIRECTORYNAME in the other one. The paths will be displayed correctly, you can browse the directories in the two panes-
2. Mark files in /LOCALPATH, and press F5 or F6 to copy them to the remote side.
3. The remote path will be shortened to /SHARENAME/DIRECTORYNAME in the confirmation dialogue, so pressing ENTER will lead to an error message. However, you can correct the path in the dialogue before confirming, then everything will work as expected.

Actual results:
An error occurs, because the shortened name does noct exist.

Expected results:
Pressing RETURN or ENTER directly after F5 or F6 should suffice to copy the files.

Does this happen every time?

Other information:
If you want to copy from the remote to the local pane or between two remote shares, the situation is worse: you cannot change the source path, so copying will always fail.

If you actually copy to a share by correcting the path, on the remote side the timestamps are not preserved. This should really behave like a local copy, in most cases you do not want to have the timestamp changed to the time of copying.

On the remote side, the user and group IDs are preserved, but are shown numerically, and not with their local names. I am aware that the remote names could be different, so this might be intentional.
Comment 1 Christoph Franzen 2009-06-04 19:46:57 UTC
The exact version of gnome-commander is 1.2.6.
Comment 2 epiotr 2009-06-11 17:35:05 UTC
Could you verify, please, if the bug is still present in the latest 1.2.7 ? If you use Ubuntu, you can packages from GetDeb repository:
Comment 3 Christoph Franzen 2009-06-11 19:49:50 UTC
I just noticed that I'm already running 1.2.7 on Debain Squeeze/Sid on another computer (i686, not AMD64, however). In the new version it worked fine for the first time I tried.

When copying to a CIFS share, however, the file name is shown without the path in the dialogue window, but it is done correctly nevertheless.

After the copy I wanted to change the directory, because the CIFS side's directory listing was nort updated. Gnome-commander crashed immediately.

I started it again, and copied the file back in the opposite direction, which also worked. 

Then I tried to copy this file again back to the share, then it said "server or workgroup SERVERNAME not found" (in german here, so it's probably not the exact message). This happened every time until I inserted the VCIFS path before the file name in the dialogue. This worked again.

Selecting "COPY" or "MOVE" is no difference in this regard, as expected.
Comment 4 Christoph Franzen 2009-06-11 19:53:16 UTC
Some weird thing about the crash I mentioned above:

After copying to a CIFS share, you can change directories on the CIFS side, but seemingly not to the "root" on the server where all the browsable shares are listed. This seems to be reproducible.

Another weird thing:

The copied file will not show uop in listings on the CIFS side until the program is restarted.
Comment 5 GNOME Infrastructure Team 2018-08-03 17:55:50 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: