You are not logged in.
Pages: 1
I can't do it with touch, but I read about a method that consists of recreating the file after changing system date.
As I have to do this in batch mode I'm wondering is this would be a safe practice (to continuosly being changing system date for a while) or if there is a possibility to get the system mad.
Offline
I can't do it with touch
Why not? EDIT: oh, because you want to change the *creation* time? Why do you need to do that in the first place?
If you are continually changing the system date / time, the system will certainly not get mad, but you might ... depending on what services or daemon processes you have running as it might cause them to behave in undesirable ways.
Last edited by Trilby (2021-10-22 19:43:43)
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
Automath wrote:I can't do it with touch
? Why do you need to do that in the first place?
To know when really a file was created; what else?
Let's say that I have a drawing that I scanned/created in 2006 why the heavens it has to have 2021 as creation date?
Offline
To know when really a file was created; what else?
Let's say that I have a drawing that I scanned/created in 2006 why the heavens it has to have 2021 as creation date?
When was the file containing the drawing scanned in 2006 created on that system?
Offline
Because that's when you created the file, the other date belongs in the metadata of the file…
Wasn't your plan to use xattr for this stuff?
Offline
Wasn't your plan to use xattr for this stuff?
Perhaps that plan blew up along with the self destructing hard drives.
Offline
Are you suggesting that we might here be dealing with a… Mission:Impossible?
Offline
Ftr. FS devs seem actually very much opposed to the very idea adding of an interface for this: https://patchwork.kernel.org/project/li … ov@fb.com/
(The discussed solution is to use xattr ;-)
Offline
To know when really a file was created; what else?
Let's say that I have a drawing that I scanned/created in 2006 why the heavens it has to have 2021 as creation date?
When was the file containing the drawing scanned in 2006 created on that system?
To know when really a file was created; what else?
Let's say that I have a drawing that I scanned/created in 2006 why the heavens it has to have 2021 as creation date?
When was the file containing the drawing scanned in 2006 created on that system?
Let's say I scanned it on the same day
Because that's when you created the file, the other date belongs in the metadata of the file…
Wasn't your plan to use xattr for this stuff?
Yes Seth, I have many plans, but that thing is overcomplicated and I'm not implementing it at the moment because I have to write it properly, but I'm befriending more the tools already given (dealing with their behaviour instead of preventing every single error, for example on Samsung phones, date of of the photos are given in it's filename), that's for now. I just wanted a quick solution for an specific case. Btw I should write a filesystem, but I have no time for that, neither I'm sure of my capabilities, I have in mind levels of deletion, scheduled deletion of files and many more stuff, even a cathegory set system instead of a hierarchical one.
seth wrote:Wasn't your plan to use xattr for this stuff?
Perhaps that plan blew up along with the self destructing hard drives.
yeah make fun of me... you'll see. I have more important things to do right now.
Btw I discovered that cause of that problem could be either a badly plugged sata cable, a general system error (my older system eas corrupted last year) or both. Then there is even more fun!
Last edited by Automath (2021-10-26 19:36:38)
Offline
loqs wrote:To know when really a file was created; what else?
Let's say that I have a drawing that I scanned/created in 2006 why the heavens it has to have 2021 as creation date?
When was the file containing the drawing scanned in 2006 created on that system?
loqs wrote:To know when really a file was created; what else?
Let's say that I have a drawing that I scanned/created in 2006 why the heavens it has to have 2021 as creation date?
When was the file containing the drawing scanned in 2006 created on that system?
Let's say I scanned it on the same day
seth wrote:Because that's when you created the file, the other date belongs in the metadata of the file…
Wasn't your plan to use xattr for this stuff?Yes Seth, I have many plans, but that thing is overcomplicated and I'm not implementing it at the moment because I have to write it properly, but I'm befriending more the tools already given (dealing with their behaviour instead of preventing every single error, for example on Samsung phones, date of of the photos are given in it's filename), that's for now. I just wanted a quick solution for an specific case. Btw I should write a filesystem, but I have no time for that, neither I'm sure of my capabilities, I have in mind levels of deletion,
scheduled deletion of files and many more stuff, even a cathegory set system instead of a hierarchical one.loqs wrote:seth wrote:Wasn't your plan to use xattr for this stuff?
Perhaps that plan blew up along with the self destructing hard drives.
yeah make fun of me... you'll see. I have more important things to do right now.
Btw I discovered that cause of that problem could be either a badly plugged sata cable, a general system error (my older system eas corrupted last year) or both. Then there is even more fun!
Ftr. FS devs seem actually very much opposed to the very idea adding of an interface for this: https://patchwork.kernel.org/project/li … ov@fb.com/
(The discussed solution is to use xattr ;-)
You see, I'm not alone on this, though this solution is not a patch but respecting creation dates for every case, evenb If I send them to the Voyager, and extending the attributes at once, obviously it's a good idea to have a low level attribute system (nobody wants a cluttered stat output), but having an additional last copy and last moved date flag wouldn't make any harm.
You scanned it on the same day in 2006 on to that the system that is reporting a creation date of 2021?
You expecting creation time to be propagated when files are copied?
Isn't that reasonable? but sometimes you do cp without -a option or whatever tool and voila.
Already in 2006, Exif was used to store such information, especially in 2021 it should be used.
Btime (birth) and ctime (change) can be changed under ext4. Only on an unmounted filesystem, and as long as you really know what you're doing.
https://stackoverflow.com/questions/638 … me-in-bash
I figured that out since flags are filesystem stuff, as are 1's and 0's but do I really want to mess with that? I'll read about exif later however.
@seth, sorry it-s difficult to deal with the many rules so many forums have.
I was just using the site the way I know that it's working, I neither like what I do and I'm trying to apply your recommendations, first to make a single comment, achieved, now how do I tag somebody? because I use quote instead of tagging because I suspect that both actions share a basic function: notifying the submitted, am I wrong? Notice that I'm doing two things at the same time learning arch linux and how to use it's forum, I'm more interested at the first one.
About doing crazy stuff to solving a problem that is not such, no i'm not doing that, leave 1's and 0's to the system not to the human, that's why there are so many of them, and yes that I learnt that: don't mess with things too complicated for a simple stuff.
And btw let's say that I come with a different file system (in the proper sense), shinny or horrible, be sure I'm not using that for storing important stuff, i'm not an idiot and i know what it's been tested for years, and more important has extended use and what some crazy people as I could come with, even debugging the file system, nothing important would be affected by that as long as i'm in charge and there's nothing critical there, it's just basic intuitive stuff. Coming with different ideas, even weird and mad it's just a different stuff, I mean I use arch linux not Inferno or plan 9, it's just a home desktop at last. I don't feel very well today, I hope that this post isn't as horrible.
Last edited by Automath (2021-10-28 19:37:21)
Offline
loqs wrote:Let's say that I have a drawing that I scanned/created in 2006 why the heavens it has to have 2021 as creation date?
When was the file containing the drawing scanned in 2006 created on that system?
Let's say I scanned it on the same day
You scanned it on the same day in 2006 on to that the system that is reporting a creation date of 2021?
You expecting creation time to be propagated when files are copied?
Offline
Already in 2006, Exif was used to store such information, especially in 2021 it should be used.
Btime (birth) and ctime (change) can be changed under ext4. Only on an unmounted filesystem, and as long as you really know what you're doing.
https://stackoverflow.com/questions/638 … me-in-bash
Offline
@Automath
1. WTF is wrong with your posting process? You bump, but edit random older posts to continue the conversation and don't get me started on "I quote everything".
Using a forum isn't complicated: post new entries only in reply, quote only the immediately relevant bits and only fix clerical errors in previous posts if the conversation has continued.
2.
Isn't that reasonable? but sometimes you do cp without -a option or whatever tool and voila.
"cp -a" does NOT preserve ctime or birth time, only atime and mtime.
3.
I'm not alone on this
You're very much alone on ideas fumbling nonsense into the underlying FS (manipulating the creation time) - the linked thread should make that very clear and I hope you've abandoned that plan by now.
as long as you really know what you're doing
The answer should be obvious by now.
Ftr, debugfs exists for the implied purpose: debugging the FS (eg. if the field went invalid)
Not to imply ones own, half-baked metadata system, contradicting the actual FS design and perverting the meaning of global attributes.
The proper answer to the OPs request is your first instinct and line (see also #5) - the in-file metadata is guaranteed to go with the file wherever it travels (even FAT)
Offline
Pages: 1