Permission issue when mounting on a computer with different UIDs

[dyne]

Permission issue when mounting on a computer with different UIDs

[jaromil]

related to #45

last discussion on mailinglist set forward the option to make FAT a default filesystem

downsides: tomb will be slower and less reliable, filenames can get scrambled

[boyska]

Another solution could be just using

chown user $mountpoint -T

when mounting the tomb. It could be a post-hook, but an option is maybe more appropriate. I'm not really sure on what to do.

EDIT: it was

chown user $mountpoint -R

[jaromil]

On Thu, 27 Oct 2011, BoySka wrote:

Another solution could be just using

chown user $mountpoint -T

can you explain? i don't find any -T on the chown manual in debian 6

[boyska]

oops, it was -R sorry for the typo

[jaromil]

On Fri, 28 Oct 2011, BoySka wrote:

oops, it was -R sorry for the typo

ack. yea then i'm definitely in favour of this solution.
maybe it should be done in background.

also worth looking inside the chown command if it does i/o on every
file even is the permission is already set...

[boyska]

maybe it should be done in background.

No, it should not be automatically done. Because you may like to use a tomb on a single machine where the owner is not always the user who is mounting it. For example, a crazy man could use a tomb for /tmp or who knows what.

also worth looking inside the chown command if it does i/o on every file even is the permission > is already set...

I suppose it does a stat and, if necessary, it changes it. Otherwise, the -c option of chown could not work.

[jaromil]

On Fri, 28 Oct 2011, BoySka wrote:

maybe it should be done in background.

No, it should not be automatically done. Because you may like to use
a tomb on a single machine where the owner is not always the user
who is mounting it. For example, a crazy man could use a tomb for
/tmp or who knows what.

well yes, any use of tomb as a shared directory among many users, like
mounting tomb as /home, should preserve the configured
ownerships. actually is not that crazy to consider tomb can be used
into initrd scripts, or call me crazy while i do it :)

so good point. but then should that be also an optional flag?

and most importantly, are you giving up on VFAT? :) if yes, thanks! :D

I suppose it does a stat and, if necessary, it changes
it. Otherwise, the -c option of chown could not work.

indeed.

[boyska]

and most importantly, are you giving up on VFAT? :) if yes, thanks! :D

No way! :P
Well, I'm trying to make tomb versatile. I'd like to add a --fs= to tomb, so that I could create my tombs with vfat. Often, it's just good that way.
But sometimes you can't/don't want, while like to make data moving easy. I want to address ALL that situations, because I need it ;)

[jaromil]

On Sun, 30 Oct 2011, BoySka wrote:

and most importantly, are you giving up on VFAT? :) if yes, thanks! :D

No way! :P

eheh

Well, I'm trying to make tomb versatile. I'd like to add a
--fs= to tomb, so that I could create my tombs with
vfat. Often, it's just good that way.

ok, i'm also in favour of --filesystem

however i think the default should stay currently used ext3

[boyska]

however i think the default should stay currently used ext3

of course it should

[boyska]

btw, I've said "it could be a post-hook". I was wrong, it couldn't, because it needs sudo.

I propose a "permission-hook", so that tomb will automatically chown the tomb IF that file is present.

[jaromil]

On Sat, 12 Nov 2011, BoySka wrote:

I propose a "permission-hook", so that tomb will automatically chown
the tomb IF that file is present.

why a hook rather than an option?

OK I answer myself: because is more of a tomb-dependent option, rather
than an environment dependent.

then the next question is:

why not a config file where such "hook switches" are configured?

and... any ideas for a tombish name for them ? :^)

ciao

[boyska]

why a hook rather than an option?

OK I answer myself: because is more of a tomb-dependent option, rather
than an environment dependent.

exactly.

why not a config file where such "hook switches" are configured?

Because we are lazy :P
I agree, but this will mean keeping retrocompatibility AND providing a
brand new way of doing things. If someone wants to create a simple way
for a (possibly complex) configuration file (.tombrc ? ), kudos. But
it's not my priority right now :)

and... any ideas for a tombish name for them ? :^)

I suggest "options" :P is it tombish enough?
ahah, you are the creative one. I am too nerd to give funny names.

[boyska]

957e820 seems to fix this. @jaromil can you confirm?

[jaromil]

yes indeed, it was coded with this discussion in mind. thanks for your argumenting :^)