option to choose tomb filesystem about tomb HOT 13 OPEN

if we make it configurable, what's the best way to check which filesystem the tomb is formatted?
I mean, without mounting it?
this is needed for instance in case one calls resize on a non-EXT tomb, the command should refuse to function.

from tomb.

On 17/01/2012 18:09, Jaromil wrote:

if we make it configurable, what's the best way to check which filesystem the tomb is formatted?
I mean, without mounting it?
this is needed for instance in case one calls resize on a non-EXT tomb, the command should refuse to function.

Well, if we want to do some quick job, we can use sfdisk.
If we wanto to do some good (but hard) job, we must use hexdump (or xdd)
to check the offset byte partition and match with a predefined set of
'tomb supported filesystem'.

This will go togheter to #45 that I
want to code (I'll start it this weekend).

If we choose one of these approaches, I can code this into #45 and then
adding this feature to 'resize' command.

Anathema

+--------------------------------------------------------------------+
|GPG/PGP KeyID: 0F26965C available on http://pgpkeys.mit.edu:11371/ |
|Fingerprint: F808 18A2 2E7D 6E7A 7A18 4062 0AA3 7BF2 0F26 965C |
| |
|http://www.msack.org |
|https://tboxes.tracciabi.li/anathema
+--------------------------------------------------------------------+

from tomb.

Bumping this issue since I want to use ZFS now on some tombs. It features history and compression.

So I'll take it from here and hack something together soon. I think of a -t option (like with mount) on lock()

Tomb also needs to save information on how it was formatted, or even better detect (with sfdisk?)

Will try ASAP. So far I can see useful options for EXT2/3/4 and ZFS, not sure what else.
FAT is not looking like a sane option since Tomb works anyway only on Linux...

from tomb.

I find -t perfectly fine for specifying filesystem.
I don't think there's any need for saving this informations; linux
should autodetect how to mount filesystems.

I think FAT is great for most tombs, but that's another story :)

from tomb.

ZFS works in a very different way than other Linux filesystems, it needs to have ad-hoc code for its usage.

Why do you think FAT is great? can you sketch a situation where it would be useful?
If you want Windows and Apple computers to access the contents of a Tomb, what about sharing it via Samba?

from tomb.

On a computer, my UID is 1001. On another one, my UID is 1002.
Sharing a tomb between these two computers is a pain.
FAT would solve these problems.

from tomb.

Don't use FAT to solve such a problem. FAT will never make it in Tomb for such a reason, it is a complex way to solve a simple problem and implies huge drawbacks.

Besides, look at line 1511:

    chown ${_uid}:${_gid} ${tombmount}
    chmod 0750 ${tombmount}

why that is not working for you?

any other reason you like to put forward to advocate use of FAT?

from tomb.

any other reason you like to put forward to advocate use of FAT?

nope. That is the only one. I'll doublecheck the chown you pointed me

from tomb.

why that is not working for you?

Probably because it does not change the ownership of the files inside the Tomb.

Indeed, that's an interesting issue. I have it also. We could take advantage of the hooks to chown -R the contents to the UID that mounted the tomb, but I see two issues there: 1) all files might not share the same UID and GID inside the Tomb for specific reasons, and 2) the user mounting the Tomb might not have the right to perform that operation (even if sudo is available).

If the user gets to the point she needs to own the files, we can safely assume she is the right owner of the Tomb, so we could simply add chown -R ${_uid} ${tombmount} (leaving the GID unchanged for files inside the tomb).

from tomb.

ACK, true there is no -R in that chown I've pointed.

Hellekin analysis here is fairly complete.
about 1) yes, "specific reasons" come in mind, however I can't think of many real life cases where they are needed and in such cases such specific usage can be fixes with post-hooks. Enough to ignore the 1) issue I'd say.
about 2) if its tomb executing the chown... should be fine.

so the suggested solution of a chown -R of the ${_uid} alone is fine for me, but it should be specified in the documentation and bypassed by the -n option, together with the hooks.

from tomb.

I agree that the cases for multiple owner are not much; I can not say the same thing for the mode; therefore, I propose

chown -R ${_uid}:${_gid} ${tombmount}
chmod 0750 ${tombmount}

So that the chmod is not recursive

from tomb.

Hmmm no. The GID is often more significant than the uid, especially for giving read-only access to some applications, or other users. Please do not touch the GID :)

from tomb.

I just want to toss one more fs onto the list. XFS if possible. Thanks for taking it into consideration.

from tomb.