← Back to team overview

desktop-packages team mailing list archive

[Bug 592748] Re: problematic default file/directory permissions when VFAT drive connected

 

*** This bug is a duplicate of bug 453605 ***
    https://bugs.launchpad.net/bugs/453605

** Also affects: udisks (Ubuntu)
   Importance: Undecided
       Status: New

** Also affects: udisks2 (Ubuntu)
   Importance: Undecided
       Status: New

** No longer affects: nautilus (Ubuntu)

** This bug has been marked a duplicate of bug 453605
   Make default mount umasks configurable

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to nautilus in Ubuntu.
https://bugs.launchpad.net/bugs/592748

Title:
  problematic default file/directory permissions when VFAT drive
  connected

Status in udisks package in Ubuntu:
  New
Status in udisks2 package in Ubuntu:
  New

Bug description:
  Binary package hint: nautilus

  The proper behavior I EXPECT:

  When I hook up an external hard drive (or USB flash drive) with one
  big VFAT partition (a VERY common thing), I want to see all
  directories/folders having these default permissions:

  drwxr-xr-x

  ...and all files to have these default permissions:

  -rw-r--r--

  Why do I need this?  Because all my folders and files under my home
  directory get those permissions by default whenever I create them.
  And I want to be able to sync/back up data to and from my VFAT drives,
  using file syncing tools like grsync, rsync, unison, conduit, etc.
  But ALL those file sync tools fail miserably when the folder and file
  permissions are not the same!

  Furthermore, it's annoying that whenever I copy files from the VFAT
  drive to my home directory, then I have to manually adjust the
  folder/file permissions as above, so that the newly-copied files have
  permissions similar to all the other folders/files in my home
  directory.  I don't want to have to do this step, as I don't think
  it's necessary.  It is NEVER the case that the "wonky" permissions
  above are useful or appropriate or helpful, in the real-world way that
  I use Ubuntu.

  Also, novice Ubuntu users should not have to know about permissions
  (let alone have to manually adjust them), this is a big turn-off for
  them!  It's a big stumbling block when newbies run into this.  You
  don't have to mess around with permissions this way in Windows!

  --------------------------------------------------------

  The buggy behavior I GET:
  When I hook up an external hard drive (or USB flash drive) with one big VFAT partition (a VERY common thing), I see folders having these permissions:

  drwx------

  ...and all files having these permissions:

  -rwxr-xr-x

  --------------------------------------------------------

  There *used to be* a workaround to this, back when gnome-mount was used:
  1. Within gconf-editor, edit "/system/storage/default_options/vfat" (Note: this no longer exists!)

  2. Delete the umask key, then add these 2 keys as follows:
  dmask=022
  fmask=133

  ...but as of Ubuntu 9.10, you can't use this workaround anymore.
  Help!

  Aargh!  I patiently tried to get this issue addressed in bug 178154
  (https://bugs.launchpad.net/gnome-mount/+bug/178154), but the bug got
  closed on me with no fix because gnome-mount is no longer in use.

  Final note: It's possible some subsystem of nautilus is to blame for
  this (But which one?  I don't know, please adjust relevant package
  accordingly if you do, and please don't just mark this as "wont-fix"
  like bug 178154).

  ProblemType: Bug
  DistroRelease: Ubuntu 10.04
  Package: nautilus 1:2.30.1-0ubuntu1
  ProcVersionSignature: Ubuntu 2.6.32-22.36-generic 2.6.32.11+drm33.2
  Uname: Linux 2.6.32-22-generic i686
  NonfreeKernelModules: nvidia
  Architecture: i386
  Date: Fri Jun 11 09:29:43 2010
  InstallationMedia: Ubuntu 9.10 "Karmic Koala" - Release i386 (20091028.5)
  ProcEnviron:
   LANG=en_CA.UTF-8
   SHELL=/bin/bash
  SourcePackage: nautilus

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/udisks/+bug/592748/+subscriptions