Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
gnome-commander
gnome-commander
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 74
    • Issues 74
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge Requests 0
    • Merge Requests 0
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
  • Operations
    • Operations
    • Incidents
    • Environments
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • CI / CD
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
  • GNOME
  • gnome-commandergnome-commander
  • Issues
  • #31

Closed
Open
Opened Jun 04, 2009 by bugzilla-migration@bugzilla-migrationReporter

SMB/CIFS path is incorrectly shortened

Submitted by Christoph Franzen

Link to original bug (#584859)

Description

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? Yes.

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.

Version: 1.2.x

Depends on

  • Bug 589069
Assignee
Assign to
2.0
Milestone
2.0
Assign milestone
Time tracking
None
Due date
None
Reference: GNOME/gnome-commander#31