Re: Fwd: Fwd: [darktable-user] Linux question
Yeah, I cannot make time to find anything either. It is easier to just consider it lost and order a new one from Amazon. ;-) Sincerely, Karim Hosein Top Rock Photography 754.999.1652 On Tue, 24 Nov 2020 at 19:29, Michael wrote: > yeah I am just a simple guy... that is too complicated for me! > Let's see find -maketime ? type file -deletefile > > see, too complicated! > > darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
Re: Fwd: Fwd: [darktable-user] Linux question
* Michael [11-24-20 19:14]: > find it easier to: > > sudo updatedb > locate > > well that might be because I never learned the find command but still > it works for me. > > On Tue, Nov 24, 2020 at 2:53 PM Anton Aylward wrote: > > > > On 24/11/2020 12:09, Patrick Shanahan wrote: > > > * Sakke K [11-24-20 12:01]: > > >> locate is a faster command than find. > > >> For example, locate _A250256.ORF.xmp > > > > > > yes, find actively scans your file structure while locate just look into > > > its database. but the database must be up-to-date or your locate will > > > fail. > > > > RTFM > > Just to clarify from TFM: > > == > > locate(1) General Commands Manual > > > > NAME > > locate - find files by name > > > > SYNOPSIS > > locate [OPTION]... PATTERN... > > > > DESCRIPTION > > locate reads one or more databases prepared by updatedb(8) and > > writes file names matching at least one of the PATTERNs to standard > > output, one per line. > > > > ... > > > > By default, locate does not check whether files found in database > > still exist (but it does require all parent directories to exist if > > the database was built with --require-visibility no). locate can > > never report files created after the most recent update of the > > relevant > > database. > > === > > > > So if you've uploaded (or relocated after uploading to a scratch directory) > > since the last update to the relevant databases, 'locate' is not going to be > > useful. 'find', by comparison deals with what is actually in the file > > system > > right now. > > > > The man page on 'updatedb' says it is refreshed daily by 'cron', but on some > > systems it is done by a systemd timer unit. > > > > Either way, it may not, on you system, be enabled by default. It isn't on > > mine. > > So I prefer to use 'find'. Which is more flexible about such matters time > > and > > size and the ability run subcommands such as 'exifgrep' on any potential > > match. > > > > > > > > darktable user mailing list > > to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org > > > > > -- > :-)~MIKE~(-: > > darktable user mailing list > to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org except that updating the locate db more than likely takes quite a bit longer than a more localized find command. but locate will be easier for you if that is what you understand and do not understand find. that said, find is very handy once you learn it as it has many applications. I automagically remove files in a particular directory based on their file-date: find -mtime +22 -type f -delete Just one example. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.orgopenSUSE Community Memberfacebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
Re: Fwd: Fwd: [darktable-user] Linux question
find it easier to: sudo updatedb locate well that might be because I never learned the find command but still it works for me. On Tue, Nov 24, 2020 at 2:53 PM Anton Aylward wrote: > > On 24/11/2020 12:09, Patrick Shanahan wrote: > > * Sakke K [11-24-20 12:01]: > >> locate is a faster command than find. > >> For example, locate _A250256.ORF.xmp > > > > yes, find actively scans your file structure while locate just look into > > its database. but the database must be up-to-date or your locate will > > fail. > > RTFM > Just to clarify from TFM: > == > locate(1) General Commands Manual > > NAME > locate - find files by name > > SYNOPSIS > locate [OPTION]... PATTERN... > > DESCRIPTION > locate reads one or more databases prepared by updatedb(8) and > writes file names matching at least one of the PATTERNs to standard > output, one per line. > > ... > > By default, locate does not check whether files found in database > still exist (but it does require all parent directories to exist if > the database was built with --require-visibility no). locate can > never report files created after the most recent update of the > relevant > database. > === > > So if you've uploaded (or relocated after uploading to a scratch directory) > since the last update to the relevant databases, 'locate' is not going to be > useful. 'find', by comparison deals with what is actually in the file system > right now. > > The man page on 'updatedb' says it is refreshed daily by 'cron', but on some > systems it is done by a systemd timer unit. > > Either way, it may not, on you system, be enabled by default. It isn't on > mine. > So I prefer to use 'find'. Which is more flexible about such matters time and > size and the ability run subcommands such as 'exifgrep' on any potential > match. > > > > darktable user mailing list > to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org > -- :-)~MIKE~(-: darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
Re: Fwd: Fwd: [darktable-user] Linux question
On 24/11/2020 12:09, Patrick Shanahan wrote: * Sakke K [11-24-20 12:01]: locate is a faster command than find. For example, locate _A250256.ORF.xmp yes, find actively scans your file structure while locate just look into its database. but the database must be up-to-date or your locate will fail. RTFM Just to clarify from TFM: == locate(1) General Commands Manual NAME locate - find files by name SYNOPSIS locate [OPTION]... PATTERN... DESCRIPTION locate reads one or more databases prepared by updatedb(8) and writes file names matching at least one of the PATTERNs to standard output, one per line. ... By default, locate does not check whether files found in database still exist (but it does require all parent directories to exist if the database was built with --require-visibility no). locate can never report files created after the most recent update of the relevant database. === So if you've uploaded (or relocated after uploading to a scratch directory) since the last update to the relevant databases, 'locate' is not going to be useful. 'find', by comparison deals with what is actually in the file system right now. The man page on 'updatedb' says it is refreshed daily by 'cron', but on some systems it is done by a systemd timer unit. Either way, it may not, on you system, be enabled by default. It isn't on mine. So I prefer to use 'find'. Which is more flexible about such matters time and size and the ability run subcommands such as 'exifgrep' on any potential match. darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
Re: Fwd: Fwd: [darktable-user] Linux question
* Sakke K [11-24-20 12:01]: > locate is a faster command than find. > For example, locate _A250256.ORF.xmp > > pe 20. marrask. 2020 klo 0.46 Bruce Williams (stu...@audio2u.com) kirjoitti: > > > Thanks for the kind words, Martin! > > > > Cheers, > > Bruce Williams. > > > > -- Forwarded message - > > From: Martin Šoltis > > Date: Fri, 20 Nov 2020, 09:28 > > Subject: Re: Fwd: Fwd: [darktable-user] Linux question > > To: Bruce Williams > > > > > > Hi Bruce, > > > > I am very glad I was able to help you. > > > > Your videos are so inspiring and I admire your work. > > > > Wish you the best. > > > > Martin > > > > > > On štvrtok 19. novembra 2020 20:19:35 CET you wrote: > > > Well, that's just a bit too bloody simple, isn't it? > > > Thanks for that! > > > > > > Cheers, > > > Bruce Williams. > > > > > > -- Forwarded message - > > > From: Martin Šoltis > > > Date: Thu, 19 Nov 2020, 23:17 > > > Subject: Re: Fwd: [darktable-user] Linux question > > > To: > > > > > > > > > Hi Bruce, > > > > > > just open DT, select all images and click on "write sidecar files" in the > > > History stack module. > > > > > > Regards > > > > > > Martin > > > > > > On štvrtok 19. novembra 2020 13:04:18 CET Bruce Williams wrote: > > > > Thanks Matt. > > > > So, is there a way to now force the creation of sidecar files? > > > > Cheers, > > > > Bruce Williams. > > > > > > > > -- Forwarded message - > > > > From: Matt Maguire > > > > Date: Thu, 19 Nov 2020, 22:58 > > > > Subject: Re: [darktable-user] Linux question > > > > To: Bruce Williams > > > > Cc: darktable-user > > > > > > > > > > > > Bruce, I assume the edits are stored purely in the darktable sqlite > > db, in > > > > your .config folder, and the XMP don't exist anywhere on the system > > due to > > > > the permissions problem you mentioned. > > > > > > > > /Matt > > > > > > > > On Thu, 19 Nov 2020 at 22:54, Bruce Williams > > wrote: > > > > > Hi all, > > > > > I have a folder which I didn't realise had been created by another > > user > > > > > account on my linux box (ie: not @bruce) > > > > > I've just noticed that the RAW files in this folder do NOT have xmp > > > > > sidecar files sitting alongside them, and I assume that the reason > > for > > > > > that > > > > > is that I imported them under my user account, and my user account > > > > > > didn't > > > > > > > > have write privileges on the folder. > > > > > But those RAW files do have keywords and development settings, which > > > > > > means > > > > > > > > that the xmp files have been written to some other location (because > > > > > > linux > > > > > > > > is clever like that!). > > > > > Anyone know where those xmp files will be? > > > > > I've changed the owner of the folder now, and would like to move the > > xmp > > > > > files to the folder so they sit with the RAW files. > > > > > Cheers, > > > > > Bruce Williams > > > > > -- > > > > > > > > > > brucewilliamsphotography.com > > > > > shuttersincpodcast.com > > > > > > > > > > e-mail | Twitter <http://twitter.com/@audio2u> > > | > > > > > LinkedIn <http://au.linkedin.com/pub/bruce-williams/1/318/489> | > > > > > > Facebook > > > > > > > > <http://www.facebook.com/audio2u> | Soundcloud > > > > > <http://www.soundcloud.com/audio2u> | Quora > > > > > <https://www.quora.com/profile/Bruce-Williams-5> > > > > > -- > > > > > > > > __ > > > > > > > > __ darktable user mailing list to unsubscribe send a mail to > > > > > darktable-user+unsubscr...@lists.darktable.org > > > > > > > > __
Re: Fwd: Fwd: [darktable-user] Linux question
locate is a faster command than find. For example, locate _A250256.ORF.xmp pe 20. marrask. 2020 klo 0.46 Bruce Williams (stu...@audio2u.com) kirjoitti: > Thanks for the kind words, Martin! > > Cheers, > Bruce Williams. > > -- Forwarded message - > From: Martin Šoltis > Date: Fri, 20 Nov 2020, 09:28 > Subject: Re: Fwd: Fwd: [darktable-user] Linux question > To: Bruce Williams > > > Hi Bruce, > > I am very glad I was able to help you. > > Your videos are so inspiring and I admire your work. > > Wish you the best. > > Martin > > > On štvrtok 19. novembra 2020 20:19:35 CET you wrote: > > Well, that's just a bit too bloody simple, isn't it? > > Thanks for that! > > > > Cheers, > > Bruce Williams. > > > > -- Forwarded message - > > From: Martin Šoltis > > Date: Thu, 19 Nov 2020, 23:17 > > Subject: Re: Fwd: [darktable-user] Linux question > > To: > > > > > > Hi Bruce, > > > > just open DT, select all images and click on "write sidecar files" in the > > History stack module. > > > > Regards > > > > Martin > > > > On štvrtok 19. novembra 2020 13:04:18 CET Bruce Williams wrote: > > > Thanks Matt. > > > So, is there a way to now force the creation of sidecar files? > > > Cheers, > > > Bruce Williams. > > > > > > -- Forwarded message - > > > From: Matt Maguire > > > Date: Thu, 19 Nov 2020, 22:58 > > > Subject: Re: [darktable-user] Linux question > > > To: Bruce Williams > > > Cc: darktable-user > > > > > > > > > Bruce, I assume the edits are stored purely in the darktable sqlite > db, in > > > your .config folder, and the XMP don't exist anywhere on the system > due to > > > the permissions problem you mentioned. > > > > > > /Matt > > > > > > On Thu, 19 Nov 2020 at 22:54, Bruce Williams > wrote: > > > > Hi all, > > > > I have a folder which I didn't realise had been created by another > user > > > > account on my linux box (ie: not @bruce) > > > > I've just noticed that the RAW files in this folder do NOT have xmp > > > > sidecar files sitting alongside them, and I assume that the reason > for > > > > that > > > > is that I imported them under my user account, and my user account > > > > didn't > > > > > > have write privileges on the folder. > > > > But those RAW files do have keywords and development settings, which > > > > means > > > > > > that the xmp files have been written to some other location (because > > > > linux > > > > > > is clever like that!). > > > > Anyone know where those xmp files will be? > > > > I've changed the owner of the folder now, and would like to move the > xmp > > > > files to the folder so they sit with the RAW files. > > > > Cheers, > > > > Bruce Williams > > > > -- > > > > > > > > brucewilliamsphotography.com > > > > shuttersincpodcast.com > > > > > > > > e-mail | Twitter <http://twitter.com/@audio2u> > | > > > > LinkedIn <http://au.linkedin.com/pub/bruce-williams/1/318/489> | > > > > Facebook > > > > > > <http://www.facebook.com/audio2u> | Soundcloud > > > > <http://www.soundcloud.com/audio2u> | Quora > > > > <https://www.quora.com/profile/Bruce-Williams-5> > > > > -- > > > > > __ > > > > > > __ darktable user mailing list to unsubscribe send a mail to > > > > darktable-user+unsubscr...@lists.darktable.org > > > > > > > > darktable user mailing list > > > to unsubscribe send a mail to > > > > darktable-user+unsubscr...@lists.darktable.org > > > > > > > > > > > > > darktable user mailing list > > to unsubscribe send a mail to > darktable-user+unsubscr...@lists.darktable.org > > > > > > > darktable user mailing list > > to unsubscribe send a mail to > darktable-user+unsubscr...@lists.darktable.org > > > > > > > darktable user mailing list to unsubscribe send a mail to > darktable-user+unsubscr...@lists.darktable.org > darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
