Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.user > #257358 > unrolled thread
| Started by | Default User <hunguponcontent@gmail.com> |
|---|---|
| First post | 2023-04-18 17:00 +0200 |
| Last post | 2023-04-19 22:40 +0200 |
| Articles | 20 on this page of 81 — 19 participants |
Back to article view | Back to linux.debian.user
/etc/fstab question (problem)? Default User <hunguponcontent@gmail.com> - 2023-04-18 17:00 +0200
Re: /etc/fstab question (problem)? Charles Curley <charlescurley@charlescurley.com> - 2023-04-18 17:40 +0200
Re: /etc/fstab question (problem)? Max Nikulin <manikulin@gmail.com> - 2023-04-18 19:00 +0200
Re: /etc/fstab question (problem)? <tomas@tuxteam.de> - 2023-04-18 21:10 +0200
Re: /etc/fstab question (problem)? Tom Furie <tom@furie.org.uk> - 2023-04-18 23:20 +0200
Re: /etc/fstab question (problem)? <tomas@tuxteam.de> - 2023-04-19 06:40 +0200
tmp on tmpfs Max Nikulin <manikulin@gmail.com> - 2023-04-19 08:20 +0200
Re: tmp on tmpfs <tomas@tuxteam.de> - 2023-04-19 08:40 +0200
Re: tmp on tmpfs Nicolas George <george@nsup.org> - 2023-04-19 09:00 +0200
Re: tmp on tmpfs tomas@tuxteam.de - 2023-04-19 10:00 +0200
Re: tmp on tmpfs Celejar <celejar@gmail.com> - 2023-04-24 18:20 +0200
Re: tmp on tmpfs <tomas@tuxteam.de> - 2023-04-24 19:10 +0200
Re: tmp on tmpfs Celejar <celejar@gmail.com> - 2023-04-24 19:40 +0200
Re: tmp on tmpfs Celejar <celejar@gmail.com> - 2023-04-24 18:20 +0200
Re: tmp on tmpfs Max Nikulin <manikulin@gmail.com> - 2023-04-19 13:10 +0200
Re: tmp on tmpfs <tomas@tuxteam.de> - 2023-04-19 20:10 +0200
Re: tmp on tmpfs songbird <songbird@anthive.com> - 2023-04-20 15:00 +0200
Re: tmp on tmpfs Vincent Lefevre <vincent@vinc17.net> - 2023-04-20 16:20 +0200
Re: tmp on tmpfs <tomas@tuxteam.de> - 2023-04-20 16:30 +0200
Re: tmp on tmpfs Vincent Lefevre <vincent@vinc17.net> - 2023-04-20 17:20 +0200
Re: tmp on tmpfs Jeffrey Walton <noloader@gmail.com> - 2023-04-20 16:30 +0200
Re: tmp on tmpfs <tomas@tuxteam.de> - 2023-04-20 16:40 +0200
Re: /etc/fstab question (problem)? songbird <songbird@anthive.com> - 2023-04-18 18:00 +0200
Re: /etc/fstab question (problem)? David Christensen <dpchrist@holgerdanske.com> - 2023-04-18 22:10 +0200
Re: /etc/fstab question (problem)? Default User <hunguponcontent@gmail.com> - 2023-04-18 23:50 +0200
Re: /etc/fstab question (problem)? Greg Wooledge <greg@wooledge.org> - 2023-04-19 00:00 +0200
Re: /etc/fstab question (problem)? David Christensen <dpchrist@holgerdanske.com> - 2023-04-19 02:00 +0200
Re: /etc/fstab question (problem)? Default User <hunguponcontent@gmail.com> - 2023-04-19 03:20 +0200
Re: /etc/fstab question (problem)? Charles Curley <charlescurley@charlescurley.com> - 2023-04-19 04:50 +0200
Re: /etc/fstab question (problem)? David Christensen <dpchrist@holgerdanske.com> - 2023-04-19 05:00 +0200
Re: /etc/fstab question (problem)? David Wright <deblis@lionunicorn.co.uk> - 2023-04-19 05:10 +0200
Re: /etc/fstab question (problem)? Stefan Monnier <monnier@iro.umontreal.ca> - 2023-04-19 05:20 +0200
Re: /etc/fstab question (problem)? David Christensen <dpchrist@holgerdanske.com> - 2023-04-19 11:20 +0200
Re: /etc/fstab question (problem)? Max Nikulin <manikulin@gmail.com> - 2023-04-19 13:10 +0200
Re: /etc/fstab question (problem)? Default User <hunguponcontent@gmail.com> - 2023-04-19 22:10 +0200
Re: /etc/fstab question (problem)? David Wright <deblis@lionunicorn.co.uk> - 2023-04-19 22:40 +0200
Re: /etc/fstab question (problem)? Default User <hunguponcontent@gmail.com> - 2023-04-19 23:00 +0200
Re: /etc/fstab question (problem)? Default User <hunguponcontent@gmail.com> - 2023-04-19 23:10 +0200
Re: /etc/fstab question (problem)? davidson <davidson@freevolt.org> - 2023-04-20 01:50 +0200
Re: /etc/fstab question (problem)? Default User <hunguponcontent@gmail.com> - 2023-04-20 03:50 +0200
Re: /etc/fstab question (problem)? songbird <songbird@anthive.com> - 2023-04-20 15:10 +0200
Re: /etc/fstab question (problem)? rhkramer@gmail.com - 2023-04-21 11:10 +0200
Re: /etc/fstab question (problem)? Greg Wooledge <greg@wooledge.org> - 2023-04-21 13:20 +0200
gitification (was Re: /etc/fstab question (problem)? songbird <songbird@anthive.com> - 2023-04-20 15:00 +0200
Re: gitification (was Re: /etc/fstab question (problem)? Stefan Monnier <monnier@iro.umontreal.ca> - 2023-04-20 15:40 +0200
Re: gitification (was Re: /etc/fstab question (problem)? songbird <songbird@anthive.com> - 2023-04-20 20:40 +0200
Re: gitification (was Re: /etc/fstab question (problem)? Stefan Monnier <monnier@iro.umontreal.ca> - 2023-04-20 22:10 +0200
Re: gitification (was Re: /etc/fstab question (problem)? songbird <songbird@anthive.com> - 2023-04-21 00:50 +0200
Re: gitification (was Re: /etc/fstab question (problem)? Jeremy Ardley <jeremy@ardley.org> - 2023-04-21 01:10 +0200
Re: gitification (was Re: /etc/fstab question (problem)? songbird <songbird@anthive.com> - 2023-04-21 19:50 +0200
Re: gitification (was Re: /etc/fstab question (problem)? Jeremy Ardley <jeremy@ardley.org> - 2023-04-20 15:40 +0200
Re: gitification (was Re: /etc/fstab question (problem)? Max Nikulin <manikulin@gmail.com> - 2023-04-20 17:30 +0200
Re: gitification (was Re: /etc/fstab question (problem)? songbird <songbird@anthive.com> - 2023-04-20 20:30 +0200
Re: gitification (was Re: /etc/fstab question (problem)? Max Nikulin <manikulin@gmail.com> - 2023-04-22 08:40 +0200
Re: gitification (was Re: /etc/fstab question (problem)? David Christensen <dpchrist@holgerdanske.com> - 2023-04-20 22:50 +0200
Re: gitification (was Re: /etc/fstab question (problem)? songbird <songbird@anthive.com> - 2023-04-21 00:50 +0200
Re: gitification (was Re: /etc/fstab question (problem)? David Christensen <dpchrist@holgerdanske.com> - 2023-04-21 04:40 +0200
Re: /etc/fstab question (problem)? Dan Ritter <dsr@randomstring.org> - 2023-04-19 22:40 +0200
Re: /etc/fstab question (problem)? David Christensen <dpchrist@holgerdanske.com> - 2023-04-19 23:10 +0200
Re: /etc/fstab question (problem)? Default User <hunguponcontent@gmail.com> - 2023-04-19 23:30 +0200
Re: /etc/fstab question (problem)? David Christensen <dpchrist@holgerdanske.com> - 2023-04-20 00:10 +0200
Re: /etc/fstab question (problem)? David Christensen <dpchrist@holgerdanske.com> - 2023-04-20 00:20 +0200
[SOLVED] Re: /etc/fstab question (problem)? Default User <hunguponcontent@gmail.com> - 2023-04-20 02:30 +0200
Re: [SOLVED] Re: /etc/fstab question (problem)? David Christensen <dpchrist@holgerdanske.com> - 2023-04-20 03:00 +0200
Re: /etc/fstab question (problem)? Max Nikulin <manikulin@gmail.com> - 2023-04-21 17:20 +0200
Re: /etc/fstab question (problem)? David Christensen <dpchrist@holgerdanske.com> - 2023-04-22 00:50 +0200
Re: /etc/fstab question (problem)? David Wright <deblis@lionunicorn.co.uk> - 2023-04-22 17:30 +0200
Re: /etc/fstab question (problem)? David Christensen <dpchrist@holgerdanske.com> - 2023-04-23 04:00 +0200
Re: /etc/fstab question (problem)? David Wright <deblis@lionunicorn.co.uk> - 2023-04-23 06:20 +0200
Re: /etc/fstab question (problem)? David Christensen <dpchrist@holgerdanske.com> - 2023-04-23 10:20 +0200
Re: /etc/fstab question (problem)? Celejar <celejar@gmail.com> - 2023-04-24 18:30 +0200
Re: /etc/fstab question (problem)? David Wright <deblis@lionunicorn.co.uk> - 2023-04-25 15:00 +0200
old memory sticks (was Re: /etc/fstab question (problem)? songbird <songbird@anthive.com> - 2023-04-23 17:20 +0200
[SOLVED]: old memory sticks songbird <songbird@anthive.com> - 2023-04-24 03:50 +0200
Re: /etc/fstab question (problem)? songbird <songbird@anthive.com> - 2023-04-20 15:10 +0200
Re: /etc/fstab question (problem)? Max Nikulin <manikulin@gmail.com> - 2023-04-20 17:20 +0200
Re: /etc/fstab question (problem)? David Wright <deblis@lionunicorn.co.uk> - 2023-04-21 06:30 +0200
Re: /etc/fstab question (problem)? <tomas@tuxteam.de> - 2023-04-21 06:50 +0200
Re: /etc/fstab question (problem)? Default User <hunguponcontent@gmail.com> - 2023-04-20 16:30 +0200
Re: /etc/fstab question (problem)? David Wright <deblis@lionunicorn.co.uk> - 2023-04-19 22:40 +0200
Re: /etc/fstab question (problem)? Default User <hunguponcontent@gmail.com> - 2023-04-19 22:40 +0200
Page 3 of 5 — ← Prev page 1 2 [3] 4 5 Next page →
| From | songbird <songbird@anthive.com> |
|---|---|
| Date | 2023-04-20 15:10 +0200 |
| Message-ID | <GmCcW-3iLz-1@gated-at.bofh.it> |
| In reply to | #257413 |
davidson wrote: ... > Consider the -a option to cp for backup/backdown operations, to > preserve all attributes (including timestamps), recursively copy > directories, and more. Read the manual for details. that's what i use by default for all copies. saves me a lot of wondering where something might have come from and also acts as a warning to me when i see something that should not have changed. since i frequenlty run into issues with git doing things i do not like to my file metadata it's something i've become a bit more wary about. ugh!, blah! and drats! songbird
[toc] | [prev] | [next] | [standalone]
| From | rhkramer@gmail.com |
|---|---|
| Date | 2023-04-21 11:10 +0200 |
| Message-ID | <GmUWd-3u3R-1@gated-at.bofh.it> |
| In reply to | #257409 |
On Wednesday, April 19, 2023 05:02:16 PM Default User wrote:
> sudo cp -r <source> <destination> from the live usb.
Recently I've been trying to get in the habit of using cp -aru because those
options do what I usually want:
* -a preserves dates (and ownership and permissions), and doesn't follow
(copy from) symbolic links
* -r recurses through subdirectories
* -u copies only if the destination file is older than the file to be copied
--
rhk
(sig revised 20230312 -- modified first paragraph, some other irrelevant
wordsmithing)
| No entity has permission to use this email to train an AI.
If you reply: snip, snip, and snip again; leave attributions; avoid HTML;
avoid top posting; and keep it "on list". (Oxford comma (and semi-colon)
included at no charge.) If you revise the topic, change the Subject: line.
If you change the topic, start a new thread.
Writing is often meant for others to read and understand (legal documents
excepted?) -- make it easier for your reader by various means, including
liberal use of whitespace (short paragraphs, separated by whitespace / blank
lines) and minimal use of (obscure?) jargon, abbreviations, acronyms, and
references.
If someone has already responded to a question, decide whether any response
you add will be helpful or not ...
A picture is worth a thousand words. A video (or "audio"): not so much --
divide by 10 for each minute of video (or audio) or create a transcript and
edit it to 10% of the original.
A speaker who uses ahhs, ums, or such may have a real physical or mental
disability, or may be showing disrespect for his listeners by not properly
preparing in advance and thinking before speaking. (That speaker might have
been "trained" to do this by being interrupted often if he pauses.) (Remember
Cicero who did not have enough time to write a short missive.)
A radio (or TV) station which broadcasts speakers with high pitched voices (or
very low pitched / gravelly voices) (which older people might not be able to
hear properly) disrespects its listeners. Likewise if it broadcasts
extraneous or disturbing sounds (like gunfire or crying), or broadcasts
speakers using their native language (with or without an overdubbed
translation).
A person who writes a sig this long probably has issues and disrespects (and
offends) a large number of readers. ;-)
'
[toc] | [prev] | [next] | [standalone]
| From | Greg Wooledge <greg@wooledge.org> |
|---|---|
| Date | 2023-04-21 13:20 +0200 |
| Message-ID | <GmWY1-3vdn-3@gated-at.bofh.it> |
| In reply to | #257459 |
On Fri, Apr 21, 2023 at 04:59:36AM -0400, rhkramer@gmail.com wrote:
> On Wednesday, April 19, 2023 05:02:16 PM Default User wrote:
> > sudo cp -r <source> <destination> from the live usb.
>
> Recently I've been trying to get in the habit of using cp -aru because those
> options do what I usually want:
>
> * -a preserves dates (and ownership and permissions), and doesn't follow
> (copy from) symbolic links
> * -r recurses through subdirectories
> * -u copies only if the destination file is older than the file to be copied
In GNU cp(1):
-a, --archive
same as -dR --preserve=all
-d same as --no-dereference --preserve=links
-R, -r, --recursive
copy directories recursively
So, your -r is redundant. It's included in the -a.
[toc] | [prev] | [next] | [standalone]
| From | songbird <songbird@anthive.com> |
|---|---|
| Date | 2023-04-20 15:00 +0200 |
| Subject | gitification (was Re: /etc/fstab question (problem)? |
| Message-ID | <GmC3f-3it0-3@gated-at.bofh.it> |
| In reply to | #257403 |
David Wright wrote: ... > I see nothing unreasonable. The only oddity to me is that the listings > you give (which are from the backups, I assume) have today's date, > which means that the backup method is not preserving the file metadata. > (If you've not used partition 5 for a while, the dates should be old.) > It doesn't affect what you're doing now, as all the originals are > heading into oblivion, but I'd be reading the backup spec sometime > to see if I could improve that. aside rant, thank gitification for that IMO. one of the worst design decisions i've come across in the modern era was the lack of git respecting file metadata. i got bit by this a few weeks ago yet again. i hate using git because of it destroying my file meta data. songbird
[toc] | [prev] | [next] | [standalone]
| From | Stefan Monnier <monnier@iro.umontreal.ca> |
|---|---|
| Date | 2023-04-20 15:40 +0200 |
| Subject | Re: gitification (was Re: /etc/fstab question (problem)? |
| Message-ID | <GmCFX-3iUE-5@gated-at.bofh.it> |
| In reply to | #257427 |
> one of the worst design decisions i've come across in
> the modern era was the lack of Git respecting file metadata.
>
> i got bit by this a few weeks ago yet again. i hate using
> Git because of it destroying my file meta data.
FWIW, I think it makes perfect sense for Git to ignore such metadata
in the context of the intended use of Git (i.e. tracking source code).
But I wish there was a concerted effort to develop/maintain "Git as
a general purpose data storage tool" where various things can be tweaked
depending on the use-case, such as storing metadata, trying to handle
terabyte sized repositories, hash-splitting large files/directories, ...
It could be a sister project of Git.
Stefan
[toc] | [prev] | [next] | [standalone]
| From | songbird <songbird@anthive.com> |
|---|---|
| Date | 2023-04-20 20:40 +0200 |
| Subject | Re: gitification (was Re: /etc/fstab question (problem)? |
| Message-ID | <GmHmh-3lGY-3@gated-at.bofh.it> |
| In reply to | #257430 |
Stefan Monnier wrote: ... > FWIW, I think it makes perfect sense for Git to ignore such metadata > in the context of the intended use of Git (i.e. tracking source code). it didn't make sense to me then and still doesn't but whatever... :) > But I wish there was a concerted effort to develop/maintain "Git as > a general purpose data storage tool" where various things can be tweaked > depending on the use-case, such as storing metadata, trying to handle > terabyte sized repositories, hash-splitting large files/directories, ... > > It could be a sister project of Git. there are other attempts which are done for it and process flows for me but i'd really prefer just a simple flag or environment variable i could set which would do it instead so then i'd be able to get rid of the gyrations. but it really sux to get a directory structure set up how i'd like it and the forget that git has this effect and then come back some time later and see the mess it's made. songbird
[toc] | [prev] | [next] | [standalone]
| From | Stefan Monnier <monnier@iro.umontreal.ca> |
|---|---|
| Date | 2023-04-20 22:10 +0200 |
| Subject | Re: gitification (was Re: /etc/fstab question (problem)? |
| Message-ID | <GmILn-3mGO-15@gated-at.bofh.it> |
| In reply to | #257445 |
>> It could be a sister project of Git.
> there are other attempts which are done for it and
> process flows for me but i'd really prefer just a
> simple flag or environment variable i could set which
> would do it instead so then i'd be able to get rid of
> the gyrations.
AFAIK the Git maintainers aren't very interested in pushing Git in that
direction (i.e. a generic file storage tool), which is why I think it
needs to be a sister project (at least at first).
BTW, the `bup` tool does add some of the needed functionality
(e.g. storing metadata), but it's not developed with an eye towards
merging some of that extra functionality into Git, and it doesn't aim to
be a "generic file storage tool" either :-(
Stefan
[toc] | [prev] | [next] | [standalone]
| From | songbird <songbird@anthive.com> |
|---|---|
| Date | 2023-04-21 00:50 +0200 |
| Subject | Re: gitification (was Re: /etc/fstab question (problem)? |
| Message-ID | <GmLgd-3nZJ-1@gated-at.bofh.it> |
| In reply to | #257447 |
Stefan Monnier wrote: ... > BTW, the `bup` tool does add some of the needed functionality > (e.g. storing metadata), but it's not developed with an eye towards > merging some of that extra functionality into Git, and it doesn't aim to > be a "generic file storage tool" either :-( i tried bup for a while but ended up just going back to using tar as my backups and depending upon other factors i may use git or not during some development but ultimately i end up ditching git. songbird
[toc] | [prev] | [next] | [standalone]
| From | Jeremy Ardley <jeremy@ardley.org> |
|---|---|
| Date | 2023-04-21 01:10 +0200 |
| Subject | Re: gitification (was Re: /etc/fstab question (problem)? |
| Message-ID | <GmLzz-3ola-1@gated-at.bofh.it> |
| In reply to | #257449 |
On 21/4/23 05:41, songbird wrote: > Stefan Monnier wrote: > > > songbird I have not used these, but there seem to be some work-arounds for storing metadata in/with git lfs has the ability to script xattr handling https://git-lfs.github.com/ These applications work directly with metadata and can be scripted into the git process: Metastore: https://github.com/przemoc/metastore Git-meta: https://github.com/chasinglogic/git-meta None of these will handle NTFS Alternate Data Streams, so archive operations between windows and linux are guaranteed to lose data and metadata. -- Jeremy (Lists)
[toc] | [prev] | [next] | [standalone]
| From | songbird <songbird@anthive.com> |
|---|---|
| Date | 2023-04-21 19:50 +0200 |
| Subject | Re: gitification (was Re: /etc/fstab question (problem)? |
| Message-ID | <Gn33r-3yIM-5@gated-at.bofh.it> |
| In reply to | #257451 |
Jeremy Ardley wrote: ... > I have not used these, but there seem to be some work-arounds for > storing metadata in/with git > > lfs has the ability to script xattr handling > > https://git-lfs.github.com/ i'll look at that one and see if it brings things to mind that i've already messed with it before. sometimes i go looking and do try things, but my recent few months have been busy with other projects. um, no, i don't want large files being shipped off or linked to some other service. that's not what my gripe is about at all. > These applications work directly with metadata and can be scripted into > the git process: > > Metastore: https://github.com/przemoc/metastore > > Git-meta: https://github.com/chasinglogic/git-meta i've dabbled with that one but not gone further. > None of these will handle NTFS Alternate Data Streams, so archive > operations between windows and linux are guaranteed to lose data and > metadata. i don't do stuff with Windows or NTFS any longer so that doesn't matter to me, i just want file attributes copied and restored properly. songbird
[toc] | [prev] | [next] | [standalone]
| From | Jeremy Ardley <jeremy@ardley.org> |
|---|---|
| Date | 2023-04-20 15:40 +0200 |
| Subject | Re: gitification (was Re: /etc/fstab question (problem)? |
| Message-ID | <GmCFX-3iUE-3@gated-at.bofh.it> |
| In reply to | #257427 |
On 20/4/23 20:10, songbird wrote: > > aside rant, > > thank gitification for that IMO. > > one of the worst design decisions i've come across in > the modern era was the lack of git respecting file metadata. > > i got bit by this a few weeks ago yet again. i hate using > git because of it destroying my file meta data. > > Not ideal, but you can store your files in a container that maintains metadata and then store that in git. Ideally you would want a container application that restores files with every metadata attribute as at insertion into the container, but for some purposes that may not be essential for all metadata elements. -- Jeremy (Lists)
[toc] | [prev] | [next] | [standalone]
| From | Max Nikulin <manikulin@gmail.com> |
|---|---|
| Date | 2023-04-20 17:30 +0200 |
| Subject | Re: gitification (was Re: /etc/fstab question (problem)? |
| Message-ID | <GmEop-3jY4-3@gated-at.bofh.it> |
| In reply to | #257427 |
On 20/04/2023 19:10, songbird wrote: > one of the worst design decisions i've come across in > the modern era was the lack of git respecting file metadata. In the case of git you can get commit time from git log. Version control systems update modification time on operations like "git checkout" or "git pull" to allow build systems, relying on timestamp comparison (make), to recompile changed files even if source tree is switched to an older version. Some build systems make decisions based on file hashes, not their modification times. It may require a daemon watching file changes to avoid recalculation of all hashes on each build. So such approach is a kind of trade-off.
[toc] | [prev] | [next] | [standalone]
| From | songbird <songbird@anthive.com> |
|---|---|
| Date | 2023-04-20 20:30 +0200 |
| Subject | Re: gitification (was Re: /etc/fstab question (problem)? |
| Message-ID | <GmHcB-3lE1-5@gated-at.bofh.it> |
| In reply to | #257441 |
Max Nikulin wrote: > On 20/04/2023 19:10, songbird wrote: >> one of the worst design decisions i've come across in >> the modern era was the lack of git respecting file metadata. > > In the case of git you can get commit time from git log. i do not want commit time, i want the file attributes to not be f'd with. i know what all you've written below but it does not apply to what i want or how i use those tools and i consider git broken that it caters to broken tools and intentionally then has to screw up information which i consider both useful and critical to how i do things. ... > Version control systems update modification time on operations like "git > checkout" or "git pull" to allow build systems, relying on timestamp > comparison (make), to recompile changed files even if source tree is > switched to an older version. to me that's broken and wrong. if i need to remake a project then i clean it out and remake it i don't rely upon anything else to do it and that is also what compiler caching is for if the project is large enough where it makes that much of a difference. i don't force another tool to destroy information. > Some build systems make decisions based on file hashes, not their > modification times. It may require a daemon watching file changes to > avoid recalculation of all hashes on each build. So such approach is a > kind of trade-off. not a choice i agree with and so i have to work around it for my purposes. songbird
[toc] | [prev] | [next] | [standalone]
| From | Max Nikulin <manikulin@gmail.com> |
|---|---|
| Date | 2023-04-22 08:40 +0200 |
| Subject | Re: gitification (was Re: /etc/fstab question (problem)? |
| Message-ID | <Gnf4B-3G4E-1@gated-at.bofh.it> |
| In reply to | #257444 |
On 21/04/2023 00:43, songbird wrote: > Max Nikulin wrote: >> On 20/04/2023 19:10, songbird wrote: >>> one of the worst design decisions i've come across in >>> the modern era was the lack of git respecting file metadata. > > i know what all you've written below but > it does not apply to what i want or how i use those tools > and i consider git broken that it caters to broken tools > and intentionally then has to screw up information which i > consider both useful and critical to how i do things. Then I have no idea what you were trying to achieve by your original message. It is perfectly valid to warn people that git is not an appropriate tool when file attributes audit is involved. I can understand if somebody is pushing you toward git. At the same time I see nothing bad in tracking config files in git. If you are looking for a backup tool that keeps metadata then it is better to ask it explicitly to to get suggestions like rdiff-backup. Ignorance may be an excuse, but you said it is not the case. For me it is too much to blame developers with harsh statements concerning design decisions just because a tool was created for different tasks. Git appeared as a tool for linux kernel, a project that relies on make. Frequent incremental rebuilds are must have for developers. Git has some weak sides, but there is no point to attack its features. Git is a great step forward in comparison to CVS and SVN. Experiments with version control systems and build tools have not seized, likely we will see better ones. Precise tracking of file attributes can cause troubles for VCS. Various file systems have different set of attributes, incompatible time precision. There is no point to track UIDs at all. I admit, for reproducible builds that include unprocessed files from repository, git behavior is not perfect. Do not confuse a conscious design choice (even if it is a trade-off) and wrong selection of a tool that is inappropriate for specific purpose. >> Some build systems make decisions based on file hashes, not their >> modification times. It may require a daemon watching file changes to >> avoid recalculation of all hashes on each build. So such approach is a >> kind of trade-off. > > not a choice i agree with and so i have to work around > it for my purposes. File hash approach is for developers relying on incremental rebuilds and caching of build results. It is a way to avoid changing of mtime on checkout. P.S. Old version of git FAQ explains taken mtime approach in the same way. Build tools relies of modification time comparison: https://archive.kernel.org/oldwiki/git.wiki.kernel.org/index.php/Git_FAQ.html#Why_isn.27t_Git_preserving_modification_time_on_files.3F (New one is rather brief https://git-scm.com/docs/gitfaq)
[toc] | [prev] | [next] | [standalone]
| From | David Christensen <dpchrist@holgerdanske.com> |
|---|---|
| Date | 2023-04-20 22:50 +0200 |
| Subject | Re: gitification (was Re: /etc/fstab question (problem)? |
| Message-ID | <GmJo5-3mTl-5@gated-at.bofh.it> |
| In reply to | #257427 |
On 4/20/23 05:10, songbird wrote: > David Wright wrote: > ... >> I see nothing unreasonable. The only oddity to me is that the listings >> you give (which are from the backups, I assume) have today's date, >> which means that the backup method is not preserving the file metadata. >> (If you've not used partition 5 for a while, the dates should be old.) >> It doesn't affect what you're doing now, as all the originals are >> heading into oblivion, but I'd be reading the backup spec sometime >> to see if I could improve that. > > aside rant, > > thank gitification for that IMO. > > one of the worst design decisions i've come across in > the modern era was the lack of git respecting file metadata. > > i got bit by this a few weeks ago yet again. i hate using > git because of it destroying my file meta data. > > > songbird Please describe your use-case(s), what the requirements are and why, and how Git is failing. David
[toc] | [prev] | [next] | [standalone]
| From | songbird <songbird@anthive.com> |
|---|---|
| Date | 2023-04-21 00:50 +0200 |
| Subject | Re: gitification (was Re: /etc/fstab question (problem)? |
| Message-ID | <GmLgd-3nZJ-3@gated-at.bofh.it> |
| In reply to | #257448 |
David Christensen wrote: ... > Please describe your use-case(s), what the requirements are and why, and > how Git is failing. i require maintaining an accurate record of the file and it's attributes - i consider that a part of the reason the file exists to begin with (otherwise why have a different file at all?). if you change a file, do a git commit then go back later and do a git restore of a different version it will not restore the file attributes of that version. so while i expect to see the right date and time stamp on a file that has been restored it isn't what happens. and no, i don't considering catering to make being broken or needing to use a time stamp to keep track of changed file a requirement, if i personally need to rebuild a project and i'm using git i would make sure to have things properly cleaned up so that it would work without me having to not properly record the file attributes (or to restore them if i need to use a different version). in my recent case of git screwing me over i had a series of files in several directories all with proper dates and time stamps and i forgot about git being a git and did a git restore and every subdirectory was corrupted and i had to go back and restore them again (and then i removed that project from using git so i'd not do it again). songbird
[toc] | [prev] | [next] | [standalone]
| From | David Christensen <dpchrist@holgerdanske.com> |
|---|---|
| Date | 2023-04-21 04:40 +0200 |
| Subject | Re: gitification (was Re: /etc/fstab question (problem)? |
| Message-ID | <GmOQN-3qfe-5@gated-at.bofh.it> |
| In reply to | #257450 |
On 4/20/23 14:51, songbird wrote: > David Christensen wrote: > ... >> Please describe your use-case(s), what the requirements are and why, and >> how Git is failing. > > i require maintaining an accurate record of the > file and it's attributes - i consider that a part of > the reason the file exists to begin with (otherwise > why have a different file at all?). > > if you change a file, do a git commit then go back > later and do a git restore of a different version it > will not restore the file attributes of that version. > so while i expect to see the right date and time > stamp on a file that has been restored it isn't what > happens. > > and no, i don't considering catering to make being > broken or needing to use a time stamp to keep track > of changed file a requirement, if i personally need > to rebuild a project and i'm using git i would make > sure to have things properly cleaned up so that it > would work without me having to not properly record > the file attributes (or to restore them if i need to > use a different version). > > in my recent case of git screwing me over i had a > series of files in several directories all with proper > dates and time stamps and i forgot about git being a > git and did a git restore and every subdirectory was > corrupted and i had to go back and restore them > again (and then i removed that project from using git > so i'd not do it again). > > > songbird So, you need preservation of mtime (?). Another reader pointed to Git work-arounds, so I will not repeat that. Another idea would be to use ZFS: 1. Create a ZFS file system for one project. 2. Check-out or create the project working directory within the ZFS file system. 3. Whenever you check-in, also create a ZFS snapshot. 4. ZFS snapshots can be accessed via the Unix file system at <mountpoint>/.zfs/snapshot. Both the data and metadata are read-only, and match the state of the file system when the snapshot was taken. 5. You can roll back a file system to the most recent snapshot with the 'zfs rollback' command. ZFS can also roll back to an older snapshot, if you are willing to destroy all intermediate snapshots. 'rsync -a' could achieve the same result without destroying snapshots. 6. Another possibility would be to make a clone based upon a snapshot. David
[toc] | [prev] | [next] | [standalone]
| From | Dan Ritter <dsr@randomstring.org> |
|---|---|
| Date | 2023-04-19 22:40 +0200 |
| Message-ID | <GmmKR-39dH-1@gated-at.bofh.it> |
| In reply to | #257400 |
Default User wrote: > > Well, now I am totally confused. > > I had hoped for, and really expected, an easy, obvious, intuitive > solution. But I guess that may be a distant memory of the good old > days, before [insert string of four-letter words here] like dbus, > systemd, and Gnome 3. And when partitions were named /dev/hda5, not > 6a105a72-f5d5-441b-b926-1e405151ee84. None of dbus, systemd, or any of the Gnome products are relevant here, and if you want to refer to a partition as /dev/nvme0n1p5, you can do that. The extended directions that people have given you are intended to keep things safe. > Does that seem reasonable? Yes, it is. -dsr-
[toc] | [prev] | [next] | [standalone]
| From | David Christensen <dpchrist@holgerdanske.com> |
|---|---|
| Date | 2023-04-19 23:10 +0200 |
| Message-ID | <GmndT-39D9-23@gated-at.bofh.it> |
| In reply to | #257400 |
On 4/19/23 13:06, Default User wrote: > On Wed, 2023-04-19 at 18:07 +0700, Max Nikulin wrote: >> On 19/04/2023 16:16, David Christensen wrote: >>> On 4/18/23 20:16, Stefan Monnier wrote: >>> >>>> You can also do >>>> >>>> mount --bind / /mnt >>>> >>>> and then look at /mnt/tmp. >>>> No need to reboot into single-user mode for that. >>> >>> +1 I like that better than the reboot/ live drive idea I posted. >> >> I think, it is the case when reboot is safer. Open file descriptors >> remain on the original partition. However I do not expect that single >> user mode or booting from live image is required. Just restore >> original >> /etc/fstab and reboot. >> >> Perhaps update-initramfs is necessary after restoring of /etc/fstab >> in >> any chosen approach. >> >> > > > Well, now I am totally confused. +1 I am confused most of the time. LOL ;-) > > I had hoped for, and really expected, an easy, obvious, intuitive > solution. But I guess that may be a distant memory of the good old > days, before [insert string of four-letter words here] like dbus, > systemd, and Gnome 3. And when partitions were named /dev/hda5, not > 6a105a72-f5d5-441b-b926-1e405151ee84. > > Sigh. > > Anyway, here is where I am at: > > I have two Clonezilla backups. > 1) a full disk backup. > 2) a "partitions" backup. > So, if things really go bad, I can theoretically revert to the setup as > of 2023-04-18, when this thread was started. > > I also have a backup of the current /tmp directory (from under the / > directory). > And I have a backup of the old tmp partition. > > Both of these tmp backups were made using a Debian Stable 11.6 > Live/install usb thumb drive, as root user. > > All of these backups are on an external usb hdd. > > Here is what was in the (root) tmp directory: > > _root_partition/tmp > total 32K > 88473604 drwxr-xr-t 8 [user] [user] 4.0K Apr 19 14:18 ./ > 88473602 drwxr-xr-x 3 [user] [user] 4.0K Apr 19 14:18 ../ > 88473608 drwxr-xr-t 2 [user] [user] 4.0K Apr 19 14:18 .font-unix/ > 88473606 drwxr-xr-t 2 [user] [user] 4.0K Apr 19 14:18 .ICE-unix/ > 88473609 drwxr-xr-t 2 [user] [user] 4.0K Apr 19 14:18 .Test-unix/ > 88473610 drwx------ 2 [user] [user] 4.0K Apr 19 14:18 tracker-extract- > files.116/ > 88473605 drwxr-xr-t 2 [user] [user] 4.0K Apr 19 14:18 .X11-unix/ > 88473607 drwxr-xr-t 2 [user] [user] 4.0K Apr 19 14:18 .XIM-unix/ > > And here is what was in the old tmp partition: > > total 48K > 88473611 drwxr-xr-t 10 root root 4.0K Apr 19 14:20 ./ > 88473603 drwxr-xr-x 3 [user] [user] 4.0K Apr 19 14:20 ../ > 88473618 drwxr-xr-t 2 root root 4.0K Apr 19 14:20 .font-unix/ > 88473615 drwxr-xr-t 2 root root 4.0K Apr 19 14:20 .ICE-unix/ > 88473620 drwx------ 2 root root 4.0K Apr 19 14:20 lost+found/ > 88473619 drwxr-xr-t 2 root root 4.0K Apr 19 14:20 .Test-unix/ > 88473624 drwx------ 2 root root 4.0K Apr 19 14:20 tracker- > extract-files.1000/ > 88473623 drwx------ 2 root root 4.0K Apr 19 14:20 tracker- > extract-files.116/ > 88473621 -r--r--r-- 1 root root 11 Apr 19 14:20 .X1024-lock > 88473622 -r--r--r-- 1 root root 11 Apr 19 14:20 .X1025-lock > 88473612 drwxr-xr-t 2 root root 4.0K Apr 19 14:20 .X11-unix/ > 88473617 drwxr-xr-t 2 root root 4.0K Apr 19 14:20 .XIM-unix/ > > As far as I can tell, there is nothing crucial in either tmp backup. > > BTW, I know nothing about bind or mount --bind. I looked them up > briefly, and decided that they are too difficult and maybe dangerous to > try to learn and use under the current circumstances. > > So here is what I am thinking of doing: > > While running from within the Debian Stable 11.6 Live/install usb thumb > drive, as root user: > > 1) On the computer's internal ssd, delete the /tmp directory and its > contents. > > 2) On the computer's internal ssd, delete the contents of the old tmp > partition, but not the partition itself. > > 3) On the computer's internal ssd, replace /etc/fstab with > /etc/fstab.original, renaming it /etc/fstab. I have already made a copy > of the current /etc/fstab as /etc/fstab.as-of-2023-04-19. > > The UUIDs of all partitions on computer's internal ssd seem to be the > same as in /etc/fstab.original. > > (Note: in /etc/fstab.original, it states "Please run 'systemctl daemon- > reload' after making changes here." Since I am doing all this from a > live usb, I do not think that applies, so I would skip that.) > > Then I would shut down, remove the usb thumb drive, and boot into the > Debian system on the computer's internal ssd. > > I hope that from then on, the system would mount the old tmp partition > on the computer's internal ssd as /tmp, re-populating it automatically, > and use it as such from then on. > > Does that seem reasonable? > > Or am I missing something, obvious or not. Subsequent to my last post, I had realizations similar to the reply by Max Nikulin: * What if root attempts to remove everything under /etc, in anticipation of mounting a file system at /etc, when one or more programs have one or more open temporary files? * What if root attempts to mount a file system at /etc when one or more programs have one or more open temporary files? Rebooting avoids having to answer the above questions, or suffer the consequences. But, I cannot address Max's point about initrd(4). At this point, I would run my daily backups, use an editor to put the original /etc entry back into /etc/fstab, forget about messing with /etc on either file system, and reboot. After reboot, I would run 'df /etc' and check where /etc is mounted. If /etc is "Mounted on /", I would run update-initramfs(8), reboot, and look again. David
[toc] | [prev] | [next] | [standalone]
| From | Default User <hunguponcontent@gmail.com> |
|---|---|
| Date | 2023-04-19 23:30 +0200 |
| Message-ID | <Gmnxg-39KT-3@gated-at.bofh.it> |
| In reply to | #257408 |
On Wed, 2023-04-19 at 14:03 -0700, David Christensen wrote: > On 4/19/23 13:06, Default User wrote: > > On Wed, 2023-04-19 at 18:07 +0700, Max Nikulin wrote: > > > On 19/04/2023 16:16, David Christensen wrote: > > > > On 4/18/23 20:16, Stefan Monnier wrote: > > > > > > > > > You can also do > > > > > > > > > > mount --bind / /mnt > > > > > > > > > > and then look at /mnt/tmp. > > > > > No need to reboot into single-user mode for that. > > > > > > > > +1 I like that better than the reboot/ live drive idea I > > > > posted. > > > > > > I think, it is the case when reboot is safer. Open file > > > descriptors > > > remain on the original partition. However I do not expect that > > > single > > > user mode or booting from live image is required. Just restore > > > original > > > /etc/fstab and reboot. > > > > > > Perhaps update-initramfs is necessary after restoring of > > > /etc/fstab > > > in > > > any chosen approach. > > > > > > > > > > > > Well, now I am totally confused. > > > +1 I am confused most of the time. LOL ;-) > > > > > > I had hoped for, and really expected, an easy, obvious, intuitive > > solution. But I guess that may be a distant memory of the good old > > days, before [insert string of four-letter words here] like dbus, > > systemd, and Gnome 3. And when partitions were named /dev/hda5, not > > 6a105a72-f5d5-441b-b926-1e405151ee84. > > > > Sigh. > > > > Anyway, here is where I am at: > > > > I have two Clonezilla backups. > > 1) a full disk backup. > > 2) a "partitions" backup. > > So, if things really go bad, I can theoretically revert to the > > setup as > > of 2023-04-18, when this thread was started. > > > > I also have a backup of the current /tmp directory (from under the > > / > > directory). > > And I have a backup of the old tmp partition. > > > > Both of these tmp backups were made using a Debian Stable 11.6 > > Live/install usb thumb drive, as root user. > > > > All of these backups are on an external usb hdd. > > > > Here is what was in the (root) tmp directory: > > > > _root_partition/tmp > > total 32K > > 88473604 drwxr-xr-t 8 [user] [user] 4.0K Apr 19 14:18 ./ > > 88473602 drwxr-xr-x 3 [user] [user] 4.0K Apr 19 14:18 ../ > > 88473608 drwxr-xr-t 2 [user] [user] 4.0K Apr 19 14:18 .font-unix/ > > 88473606 drwxr-xr-t 2 [user] [user] 4.0K Apr 19 14:18 .ICE-unix/ > > 88473609 drwxr-xr-t 2 [user] [user] 4.0K Apr 19 14:18 .Test-unix/ > > 88473610 drwx------ 2 [user] [user] 4.0K Apr 19 14:18 tracker- > > extract- > > files.116/ > > 88473605 drwxr-xr-t 2 [user] [user] 4.0K Apr 19 14:18 .X11-unix/ > > 88473607 drwxr-xr-t 2 [user] [user] 4.0K Apr 19 14:18 .XIM-unix/ > > > > And here is what was in the old tmp partition: > > > > total 48K > > 88473611 drwxr-xr-t 10 root root 4.0K Apr 19 14:20 ./ > > 88473603 drwxr-xr-x 3 [user] [user] 4.0K Apr 19 14:20 ../ > > 88473618 drwxr-xr-t 2 root root 4.0K Apr 19 14:20 .font- > > unix/ > > 88473615 drwxr-xr-t 2 root root 4.0K Apr 19 14:20 .ICE-unix/ > > 88473620 drwx------ 2 root root 4.0K Apr 19 14:20 > > lost+found/ > > 88473619 drwxr-xr-t 2 root root 4.0K Apr 19 14:20 .Test- > > unix/ > > 88473624 drwx------ 2 root root 4.0K Apr 19 14:20 tracker- > > extract-files.1000/ > > 88473623 drwx------ 2 root root 4.0K Apr 19 14:20 tracker- > > extract-files.116/ > > 88473621 -r--r--r-- 1 root root 11 Apr 19 14:20 .X1024- > > lock > > 88473622 -r--r--r-- 1 root root 11 Apr 19 14:20 .X1025- > > lock > > 88473612 drwxr-xr-t 2 root root 4.0K Apr 19 14:20 .X11-unix/ > > 88473617 drwxr-xr-t 2 root root 4.0K Apr 19 14:20 .XIM-unix/ > > > > As far as I can tell, there is nothing crucial in either tmp > > backup. > > > > BTW, I know nothing about bind or mount --bind. I looked them up > > briefly, and decided that they are too difficult and maybe > > dangerous to > > try to learn and use under the current circumstances. > > > > So here is what I am thinking of doing: > > > > While running from within the Debian Stable 11.6 Live/install usb > > thumb > > drive, as root user: > > > > 1) On the computer's internal ssd, delete the /tmp directory and > > its > > contents. > > > > 2) On the computer's internal ssd, delete the contents of the old > > tmp > > partition, but not the partition itself. > > > > 3) On the computer's internal ssd, replace /etc/fstab with > > /etc/fstab.original, renaming it /etc/fstab. I have already made a > > copy > > of the current /etc/fstab as /etc/fstab.as-of-2023-04-19. > > > > The UUIDs of all partitions on computer's internal ssd seem to be > > the > > same as in /etc/fstab.original. > > > > (Note: in /etc/fstab.original, it states "Please run 'systemctl > > daemon- > > reload' after making changes here." Since I am doing all this from > > a > > live usb, I do not think that applies, so I would skip that.) > > > > Then I would shut down, remove the usb thumb drive, and boot into > > the > > Debian system on the computer's internal ssd. > > > > I hope that from then on, the system would mount the old tmp > > partition > > on the computer's internal ssd as /tmp, re-populating it > > automatically, > > and use it as such from then on. > > > > Does that seem reasonable? > > > > Or am I missing something, obvious or not. > > > Subsequent to my last post, I had realizations similar to the reply > by > Max Nikulin: > > * What if root attempts to remove everything under /etc, in > anticipation > of mounting a file system at /etc, when one or more programs have one > or > more open temporary files? > > * What if root attempts to mount a file system at /etc when one or > more > programs have one or more open temporary files? > > > Rebooting avoids having to answer the above questions, or suffer the > consequences. > > > But, I cannot address Max's point about initrd(4). > > > At this point, I would run my daily backups, use an editor to put the > original /etc entry back into /etc/fstab, forget about messing with > /etc > on either file system, and reboot. After reboot, I would run 'df > /etc' > and check where /etc is mounted. If /etc is "Mounted on /", I would > run > update-initramfs(8), reboot, and look again. > > > David > I'm afraid I don't quit understand why 'If /etc is "Mounted on /", I would run update-initramfs(8), reboot, and look again." Shouldn't etc always be expected to be mounted under /, as in /etc? For example, right now on my computer: df /etc Filesystem 1K-blocks Used Available Use% Mounted on /dev/nvme0n1p2 23854928 5841492 16776344 26% / And, would there be anything wrong with, either way, running update- initramfs? Would that be run as: sudo update-initramfs -uv ?
[toc] | [prev] | [next] | [standalone]
Page 3 of 5 — ← Prev page 1 2 [3] 4 5 Next page →
Back to top | Article view | linux.debian.user
csiph-web