netatalk-admins — List for general netatalk community support

Re: [Netatalk-admins] not deleteable files via finder

[Andres V. <te...@sm...>]

Updates on this...

1.  Recent, newer versions of netatalk: only a couple of bad CNID after 
a reboot instead of tens of thousands.

2.  Scanning with dbd was >5x faster, even though the file system cache 
was cold.

On 5/17/25 6:44 PM, Andres Valloud wrote:
> FWIW --- running
> 
>      #> dbd -tF /path/to/apf.conf /mount/where/this/occurs
> 
> tends to solve the misbehavior.
> 
> If Netatalk is serving files from Linux, running the above after the 
> server reboots reports loads of files with bad CNIDs almost every time.
> 
> On 5/16/25 6:24 AM, Michael Grundmann wrote:
>> Hi,
>>
>> i can't see some Error-Messages, but on all servers installed 
>> netatalk, we have random files, which you can't delete.
>> Finder delete - sometime later they are "on" again.
>>
>> The question is only - does you all have that, too?
>>
>>
> 
> 
> 
> _______________________________________________
> Netatalk-admins mailing list
> Net...@li...
> https://lists.sourceforge.net/lists/listinfo/netatalk-admins

[Netatalk-admins] Call for beta testing: SQLite CNID backend

[Daniel M. <da...@mi...>]

Major netatalk news: we now support SQLite as the CNID database backend for the AFP file server, in the main development branch.

Why is this big news you ask? Thank you for the great question! For the last two decades (since at least v1.5 in 2002) netatalk has been using Berkeley DB as the backend for managing CNID records. BDB is a great database, but it has been slowly dying ever since Oracle acquired it in 2006. In recent years, it's started getting flagged as obsolete by several OS distributions (Alpine, Debian etc.) so we have a semi-urgent need to find an alternative.

Enter SQLite: A popular, actively developed, and super fast embedded database engine! Just like DBD, it stores it database in a simple file on the file system, no need to juggle a stand-alone database instance with authentication, networking and so on.

Now I'm looking for beta testing volunteers to get some data from the field. If you have an existing netatalk 4.x deployment, this is how you convert your volumes to the new backend:


### Step 1 - Back up your data

I'm not kidding. You need to take a full copy of both the shared volume dir, as well as the CNID database dir for your volume. The conversion process is destructive and may lead to data loss.


### Step 2 - Build and install netatalk with SQLite support

For this you need sqlite3 library and development headers. See the build.yml file for examples of packages to install.

Once you have the required packages on your system, the Meson build system will detect and build the sqlite CNID backend by default.


### Step 3 - Configure netatalk to use the SQLite backend

In the relevant volume sections in your afp.conf, put this option:

`cnid scheme = sqlite`


### Step 4 - Convert from an earlier CNID scheme

When using the SQLite backend with an existing volume, you need to rebuild the CNID database in the new scheme.

After updating afp.conf, start the netatalk daemon, but DON'T try to connect to the shared volume yet.

First you need to run this command with root privileges:

`dbd -f /path/to/shared/volume`

Inspect the output from the dbd tool and make sure there aren't any errors. If you see an error, please report a bug with the netatalk project, attach the log, SQLite database dump, and as much details about your volume as possible!


### Step 5 - Connect to the AFP server

Now you should be able to connect to and use the converted volume as usual!


### What to look out for

-   That actual, long-lived organic volumes can be converted.
-   Concurrency. Can multiple users connect and do intensive file operations concurrently (in particular write operations)
-   Cross-platform. I've actively tested on Debian, Fedora, and macOS.

I'm looking forward to your bug reports. :)

### Troubleshooting

If you want thorough debug logs for the CNID library, this is a good log level setting:

`log level = default:info cnid:maxdebug`

To dump a SQLite database to stdout, you can do something like:

`sqlite3 /var/netatalk/CNID/myvolume/myvolume.sqlite .dump`

Sample output:

PRAGMA foreign_keys=OFF; BEGIN TRANSACTION; CREATE TABLE volumes (VolUUID CHAR(32) PRIMARY KEY, VolPath TEXT(4096), Stamp BINARY(8), Depleted INT); INSERT INTO volumes VALUES('C5DC147DD05B3440BE95D4E6A3397768','/opt/afplite','?ah',0); CREATE TABLE IF NOT EXISTS "C5DC147DD05B3440BE95D4E6A3397768" (Id INTEGER PRIMARY KEY AUTOINCREMENT,Name VARCHAR(255) NOT NULL,Did INTEGER NOT NULL,DevNo INTEGER NOT NULL,InodeNo INTEGER NOT NULL,UNIQUE (Did, Name),UNIQUE (DevNo, InodeNo)); INSERT INTO C5DC147DD05B3440BE95D4E6A3397768 VALUES(17,'Navigator for Pucko',2,16777239,74852120); INSERT INTO C5DC147DD05B3440BE95D4E6A3397768 VALUES(18,'TheVolumeSettingsFolder',2,16777239,74848959); INSERT INTO C5DC147DD05B3440BE95D4E6A3397768 VALUES(19,'Web Pages',2,16777239,74863775); INSERT INTO C5DC147DD05B3440BE95D4E6A3397768 VALUES(20,'default.html',19,16777239,74863778); DELETE FROM sqlite_sequence; INSERT INTO sqlite_sequence VALUES('C5DC147DD05B3440BE95D4E6A3397768',100); CREATE INDEX idx_volpath ON volumes(VolPath); COMMIT;

[Netatalk-admins] Netatalk 4.2.4

[Daniel M. <da...@mi...>]

Netatalk bugfix release v4.2.4 is available. Find the release notes and tarballs at:

https://netatalk.io/4.2/ReleaseNotes4.2.4

The changes in this release concern primarily Solaris and macOS users.
Solaris 11.4.81 CBE, released earlier this May, introduced major version bumps of all compilers and FLOSS packages.
This led to a gcc compiler error when building netatalk with PAM which is addressed in this release.

On macOS, if you build against libraries installed with Homebrew, you now have to use the newly introduced -Dwith-homebrew=true flag in meson.
This change was made in order to avoid side effects when building netatalk on macOS or Linux when Homebrew was installed, notably when packaging a netatalk MacPorts port.

Finally, a handful of man pages got improved verbiage and syntax, to appease the Debian lintian grammar checker.

As always, thank you to the community for all your feedback!

Sincerely,

Daniel

Re: [Netatalk-admins] not deleteable files via finder

[Andres V. <te...@sm...>]

FWIW --- running

	#> dbd -tF /path/to/apf.conf /mount/where/this/occurs

tends to solve the misbehavior.

If Netatalk is serving files from Linux, running the above after the 
server reboots reports loads of files with bad CNIDs almost every time.

On 5/16/25 6:24 AM, Michael Grundmann wrote:
> Hi,
> 
> i can't see some Error-Messages, but on all servers installed netatalk, 
> we have random files, which you can't delete.
> Finder delete - sometime later they are "on" again.
> 
> The question is only - does you all have that, too?
> 
> 

Re: [Netatalk-admins] not deleteable files via finder

[Andy L. <and...@gm...>]

Hi Michael,

Yes, and the Netatalk version too :)

Do the random files start with “._” or are there random folders named .AppleDouble?
You may also see __MACOSX.

If yes, these are Apple resource fork files which are created automatically by Apple clients.

Apple Resource Forks are stored by Netatalk as Extended Attributes, which are written to disk using System Attributes (on filesystems with system attribute support), or written to disk using secondary files (files prefixed with “._”) if the file system does not support extended attributes or system attributes.

The Netatalk afp.conf configuration file needs to have the correct settings to match your filesystem and its capabilities, to ensure resource forks are written and read in an optimal way.

These ._ files and .AppleDouble, can be inspected using the ‘ad’ tool (https://www.mankier.com/1/ad).
See also https://en.m.wikipedia.org/wiki/AppleSingle_and_AppleDouble_formats

What filesystem are you using? ZFS, EXT3/4, XFS, BTRFS etc?

What Operating System/Distro are you using?

What version of Netatalk are you using?

Andy.


> On 17 May 2025, at 17:56, Daniel Markstedt <da...@mi...> wrote:
> Hi Michael,
> 
> In addition to all of Andy's suggestions, can you please also let us know what Netatalk version you are running?
> 
> Thank you!
> 
> Daniel
> 
> 
> 
> 
> On Friday, May 16th, 2025 at 3:42 PM, Michael Grundmann <mi...@li...> wrote:
> 
> 
> 
>> Hi,
> 
>> i can't see some Error-Messages, but on all servers installed netatalk,
>> we have random files, which you can't delete.
>> Finder delete - sometime later they are "on" again.
> 
>> The question is only - does you all have that, too?
> 
> 
>> --
>> Gruß Michael
> 
>> Wenn du verstehst, was du tust, wirst du nichts lernen
> 
> 
> 
>> _______________________________________________
>> Netatalk-admins mailing list
>> Net...@li...
>> https://lists.sourceforge.net/lists/listinfo/netatalk-admins
> _______________________________________________
> Netatalk-admins mailing list
> Net...@li...
> https://lists.sourceforge.net/lists/listinfo/netatalk-admins

Re: [Netatalk-admins] not deleteable files via finder

[Daniel M. <da...@mi...>]

Hi Michael,

In addition to all of Andy's suggestions, can you please also let us know what Netatalk version you are running?

Thank you!

Daniel




On Friday, May 16th, 2025 at 3:42 PM, Michael Grundmann <mi...@li...> wrote:

> 

> 

> Hi,
> 

> i can't see some Error-Messages, but on all servers installed netatalk,
> we have random files, which you can't delete.
> Finder delete - sometime later they are "on" again.
> 

> The question is only - does you all have that, too?
> 

> 

> --
> Gruß Michael
> 

> Wenn du verstehst, was du tust, wirst du nichts lernen
> 

> 

> 

> _______________________________________________
> Netatalk-admins mailing list
> Net...@li...
> https://lists.sourceforge.net/lists/listinfo/netatalk-admins

Re: [Netatalk-admins] not deleteable files via finder

[Andy L. <and...@gm...>]

Hi Michael,

This is a known issue which is difficult to reproduce and diagnose.

Hi Daniel, this is the same issue I reported which I believe started back sometime around 3.x.

Michael, if you restart Netatalk you will be able to delete those files again. But the issue will reoccur after a while.

The issue is triggered by viewing/reading certain files (appears to be random, I’m sure there is some commonality I have not figured out yet), which I think corrupts a file descriptor or leaks a lock on the Netatalk side.
This happens regardless of `afp read locks = no` or `ignored attributes = all` in afp.conf.

It also does not seem to matter what software or scripts read the files.


Michael, What filesystem and OS are you using on the Netatalk server? I’m using OpenZFS with FreeBSD.
What MacOS client version(s) are you using when this happens?

Do you use resource forks? (Finder creates resource forks automatically, but are you also setting custom forks?)

The next steps when the issue occurs;
- edit the afp.conf file, increase the logging level to “maxdebug”.
- empty the Netatalk log file
- send SIGHUP to Netatalk (usually ‘kill -HUP <Netatalk Process ID>’)
- try and delete the file which cannot be deleted
- copy the Netatalk log to a different filename.

The idea is for the log file to contain nothing else but the maxdebug logs for the delete file operation.

SIGHUP will make Netatalk reload afp.conf without restarting (as restarting temporarily fixes the issue).

Please open a bug ticket on GitHub attaching the maxdebug log.

Good luck and thanks for reporting.
PS; I’m just another community user, not a developer.
I’ve been waiting for this issue to reoccur so I can do the same above..

Andy


> On 16 May 2025, at 23:42, Michael Grundmann <mi...@li...> wrote:
> Hi,
> 
> i can't see some Error-Messages, but on all servers installed netatalk, we have random files, which you can't delete.
> Finder delete - sometime later they are "on" again.
> 
> The question is only - does you all have that, too?
> 
> 
> --
> Gruß Michael
> 
> Wenn du verstehst, was du tust, wirst du nichts lernen
> 
> 
> 
> _______________________________________________
> Netatalk-admins mailing list
> Net...@li...
> https://lists.sourceforge.net/lists/listinfo/netatalk-admins

[Netatalk-admins] not deleteable files via finder

[Michael G. <mi...@li...>]

Hi,

i can't see some Error-Messages, but on all servers installed netatalk, 
we have random files, which you can't delete.
Finder delete - sometime later they are "on" again.

The question is only - does you all have that, too?


-- 
Gruß Michael

Wenn du verstehst, was du tust, wirst du nichts lernen

[Netatalk-admins] Netatalk 4.2.3

[Daniel M. <da...@mi...>]

Bugfix release 4.2.3 is available. As usual, the release notes are here.

https://github.com/Netatalk/netatalk/releases/tag/netatalk-4-2-3

This time, we have fixed a handful of issues that affected OpenWrt (thanks Antonio P!)
Notably, a long-standing bug where the config file passed to netatalk with the -F parameter wasn't properly interpreted.

We have also adopted a few improvements that benefit Alpine Linux in particular, in preparation of updating the downstream packaging.
Notably, an OpenRC init script with better dependencies and support for the reload command.

As always, a big thanks to everyone who have contributed patches, bug reports and feedback!

Daniel

[Netatalk-admins] Netatalk 4.2.2

[Daniel M. <da...@mi...>]

Bugfix release Netatalk 4.2.2 is available.
Find release notes and tarballs below.

https://github.com/Netatalk/netatalk/releases/tag/netatalk-4-2-2

This release contains overhauled documentation, improvements to the netatalk webmin module, and significant new containerization capabilities.

Notable for downstream packagers is that pandoc is now an option for generating the documentation from markdown sources.
When the build system finds pandoc, is will choose the converter app in this order: pandoc > cmark-gfm > cmark

Please report any bugs or feedback!

Sincerely,

Daniel

[Netatalk-admins] Netatalk 4.2.1

[Daniel M. <da...@mi...>]

A new bugfix release, Netatalk 4.2.1, is available.
It fixes a handful of bugs both new and old.
Notably, in 4.2.0 we changed EA fallback to AD, which had unintended side effects.
Therefore the EA fallback is now "none" again, which is what it's been since 3.0.

Find the release notes and tarballs below.


https://github.com/Netatalk/netatalk/releases/tag/netatalk-4-2-1

We introduced a few new build system options for downstream packaging convenience.
Check out the release notes for details.

A minor breaking change is that the former Compile chapter in the html manual has now been transitioned to a COMPILATION.md readme.
So you will see one less html manual page, and one more readme when building the documentation.

A big thanks to the community for using Netatalk and reporting bugs!

Daniel

Re: [Netatalk-admins] Removing old documentation from website

[Bradley C. <the...@gm...>]

Hi Daniel et al,

I have no personal impediments to upgrading Netatalk.  I'm already running
4.1.2 and am perfectly happy with using the latest version going forward.
My concern was mainly about preserving the archived data.

I enthusiastically installed version 4.1.2 *because* of the project's
decision to restore support for AppleTalk.  And the timing couldn't have
been better.  This decision enabled a number of people to participate in
#Marchintosh and #Globaltalk in fun and unexpected ways through printing.

Two people worked together to write a Python script that would scrape the
above hashtags from Mastodon and Bluesky and dump the posts into an Aldus
Pagemaker document.  This became the "#Marcintosh Newsletter" and the
results were sent to everyone's printers every night for most of the month.

Another fun use of printers was the Scavenger Hunt run by "@kalleboo" .  It
started as a set of 6 cryptic logic puzzles that were randomly sent to
peoples' printers.  With over 40 printers online, many people received the
same puzzle (this was done intentionally for redundancy in case of printing
errors, operator inattention, or failure to share on social media).  Those
puzzles required coördination on Mastodon + Bluesky to solve.  Some of the
puzzle clues were cleverly hidden in shared folders across the #Globaltalk.
Additionally, @kalleboo made extensive use of Hypercard for this game.  One
puzzle only revealed the key word after typing a secret phrase.  The game
concluded with a Hypercard app that was disguised as a blank icon in a
Finder folder, with a single word as its label.  The final puzzle would
only unlock when you entered the entire phrase (gleaned from solving the
rest of the puzzles).  The solution was checked server-side, so nobody
could cheat by inspecting the Hypercard file.  Everyone who solved it
received a "high resolution trophy" as a printout.  The complexity of the
game and the cleverness of these puzzles quickly drew favorable comparisons
to the game "The Fool's Errand" by puzzle genius Cliff Johnson.

Karl Baron wrote a post-mortem about the game here:
https://globaltalk.network/index.php?page=The%20GlobalTalk%20Scavenger%20Hunt%202025







On Sun, Apr 6, 2025 at 1:59 PM Daniel Markstedt <da...@mi...> wrote:

> Hi Brad,
>
> It sounds like you were able to make good use of the PAP print server!
>
> Are you asking about supported Netatalk versions for a specific reason?
>
> I obviously would prefer if everyone used the very latest version of the
> software.
> But I'm curious to hear if there are any impediments to upgrading.
>
> With regards to old manual backups: All data is effectively backed up in
> the git history of the netatalk.io source code repository.
>
> For ease of finding it later, I created a branch now on the commit before
> I removed the old manuals:
>
> https://github.com/Netatalk/netatalk.io/tree/old-manuals/public
>
> Cheers!
>
> Daniel
>
> On Sunday, April 6th, 2025 at 9:58 PM, The Iron Giant <
> the...@gm...> wrote:
>
> >
>
> >
>
> > Hello,
> >
>
> > I'm new to the Netatalk list and a new user of the project itself. After
> struggling to get "papd" working on a Raspberry Pi 4B—it was getting stuck
> on an unseen space character on an empty line—I submitted the FR to
> recommend a change to config parsing.
> >
>
> > After catching this issue, I was able to set up papd and participate in
> #Marchintosh. Lots of people sent print jobs to my modern Brother laser
> printer from their vintage Macs over #GlobalTalk. Thank you for considering
> that FR and working to include it on a future release for ease of use.
> >
>
> > I had a couple of quick questions about the archival of the old manuals:
> >
>
> > 1. Is 4.2.0 now the only supported version, and all others below this
> have been deprecated?
> >
>
> > 2. Are the deprecated manuals backed up somewhere else other than
> Sourceforge?
> >
>
> > Thanks,
> > Brad
> >
>
> > —Sent from my iPhone
> >
>
> > > On Apr 6, 2025, at 10:47 AM, Daniel Markstedt da...@mi...
> wrote:
> > >
>
> > > Thanks for the suggestion. I did this now.
> > >
>
> > > The tarball on SourceForge has been cleaned up!
> > >
>
> > > > On Sunday, April 6th, 2025 at 7:18 PM, Andres Valloud
> te...@sm... wrote:
> > >
>
> > > > Here's a suggestion. In here,
> > >
>
> > > > https://netatalk.io/documentation
> > >
>
> > > > under Supplemental Documentation, a link that says something like
> > > > "archived manuals for previous versions".
> > >
>
> > > > Also FYI the tarball has empty directories for 1.5 and 1.6 (other
> than
> > > > .gitignore files).
> > >
>
> > > > On 4/6/25 1:36 AM, Daniel Markstedt wrote:
> > >
>
> > > > > Do you have a suggestion a good place to host this tarball, so
> that it can be discovered by anyone who needs it?
> > >
>
> > > > > If it's a question of retention, we will always have the git
> history of the Netatalk/netatalk.io repo.
> > > > > You can go back to earlier commits and get any manual that you
> need.
> > >
>
> > > > > https://github.com/Netatalk/netatalk.io/tree/main/public
> > >
>
> > > > > On Saturday, April 5th, 2025 at 11:47 PM, Andres Valloud
> te...@sm... wrote:
> > > > >
>
> > > > > > Did you consider a section of old docs tarballed in their
> current state?
> > > > > > On 4/5/25 2:11 PM, Daniel Markstedt wrote:
> > > > > >
>
> > > > > > > The Netatalk website has been distributing every manual
> revision since
> > > > > > > 2.0.2 in 2005.
> > > > > > > 20 years later, this has now grown to a massive sprawl of html
> pages,
> > > > > > > since we're keeping copies of every minor feature release.
> > > > > > > Apart from the massive sprawl, search engines tend to favor
> the oldest
> > > > > > > versions of these manual pages.
> > > > > > > You consistently get hits on decade-old docs when googling for
> specific
> > > > > > > netatalk options and components.
> > > > > > > Therefore, I plan to start replacing very old docs with
> redirects to the
> > > > > > > latest docs.
> > > > > > > Old docs can still be recovered in git revision history, or
> regenerated
> > > > > > > from docbook sources if needed.
> > > > > > > In phase one, I plan to remove docs for release versions that
> are
> > > > > > > already EOL: 2.0, 2.1, 2.2, 2.3, 3.0 and 4.0.
> > > > > > > I'm open to suggestions about the ideal end state.
> > > > > > > My preference would be to host a single version of the manual
> for the
> > > > > > > latest stable version.
> > > > > > > But if people find older manuals useful then we can debate it.
> > >
>
> > > > > > > Cheers,
> > > > > > > Daniel
> > > > > > > _______________________________________________
> > > > > > > Netatalk-admins mailing list
> > > > > > > Net...@li...
> > > > > > > https://lists.sourceforge.net/lists/listinfo/netatalk-admins
> > > > > > > _______________________________________________
> > > > > > > Netatalk-admins mailing list
> > > > > > > Net...@li...
> > > > > > > https://lists.sourceforge.net/lists/listinfo/netatalk-admins
> > > > > > > <signature.asc>

Re: [Netatalk-admins] Removing old documentation from website

[Daniel M. <da...@mi...>]

Hi Brad,

It sounds like you were able to make good use of the PAP print server!

Are you asking about supported Netatalk versions for a specific reason?

I obviously would prefer if everyone used the very latest version of the software.
But I'm curious to hear if there are any impediments to upgrading.

With regards to old manual backups: All data is effectively backed up in the git history of the netatalk.io source code repository.

For ease of finding it later, I created a branch now on the commit before I removed the old manuals:

https://github.com/Netatalk/netatalk.io/tree/old-manuals/public

Cheers!

Daniel

On Sunday, April 6th, 2025 at 9:58 PM, The Iron Giant <the...@gm...> wrote:

> 

> 

> Hello,
> 

> I'm new to the Netatalk list and a new user of the project itself. After struggling to get "papd" working on a Raspberry Pi 4B—it was getting stuck on an unseen space character on an empty line—I submitted the FR to recommend a change to config parsing.
> 

> After catching this issue, I was able to set up papd and participate in #Marchintosh. Lots of people sent print jobs to my modern Brother laser printer from their vintage Macs over #GlobalTalk. Thank you for considering that FR and working to include it on a future release for ease of use.
> 

> I had a couple of quick questions about the archival of the old manuals:
> 

> 1. Is 4.2.0 now the only supported version, and all others below this have been deprecated?
> 

> 2. Are the deprecated manuals backed up somewhere else other than Sourceforge?
> 

> Thanks,
> Brad
> 

> —Sent from my iPhone
> 

> > On Apr 6, 2025, at 10:47 AM, Daniel Markstedt da...@mi... wrote:
> > 

> > Thanks for the suggestion. I did this now.
> > 

> > The tarball on SourceForge has been cleaned up!
> > 

> > > On Sunday, April 6th, 2025 at 7:18 PM, Andres Valloud te...@sm... wrote:
> > 

> > > Here's a suggestion. In here,
> > 

> > > https://netatalk.io/documentation
> > 

> > > under Supplemental Documentation, a link that says something like
> > > "archived manuals for previous versions".
> > 

> > > Also FYI the tarball has empty directories for 1.5 and 1.6 (other than
> > > .gitignore files).
> > 

> > > On 4/6/25 1:36 AM, Daniel Markstedt wrote:
> > 

> > > > Do you have a suggestion a good place to host this tarball, so that it can be discovered by anyone who needs it?
> > 

> > > > If it's a question of retention, we will always have the git history of the Netatalk/netatalk.io repo.
> > > > You can go back to earlier commits and get any manual that you need.
> > 

> > > > https://github.com/Netatalk/netatalk.io/tree/main/public
> > 

> > > > On Saturday, April 5th, 2025 at 11:47 PM, Andres Valloud te...@sm... wrote:
> > > > 

> > > > > Did you consider a section of old docs tarballed in their current state?
> > > > > On 4/5/25 2:11 PM, Daniel Markstedt wrote:
> > > > > 

> > > > > > The Netatalk website has been distributing every manual revision since
> > > > > > 2.0.2 in 2005.
> > > > > > 20 years later, this has now grown to a massive sprawl of html pages,
> > > > > > since we're keeping copies of every minor feature release.
> > > > > > Apart from the massive sprawl, search engines tend to favor the oldest
> > > > > > versions of these manual pages.
> > > > > > You consistently get hits on decade-old docs when googling for specific
> > > > > > netatalk options and components.
> > > > > > Therefore, I plan to start replacing very old docs with redirects to the
> > > > > > latest docs.
> > > > > > Old docs can still be recovered in git revision history, or regenerated
> > > > > > from docbook sources if needed.
> > > > > > In phase one, I plan to remove docs for release versions that are
> > > > > > already EOL: 2.0, 2.1, 2.2, 2.3, 3.0 and 4.0.
> > > > > > I'm open to suggestions about the ideal end state.
> > > > > > My preference would be to host a single version of the manual for the
> > > > > > latest stable version.
> > > > > > But if people find older manuals useful then we can debate it.
> > 

> > > > > > Cheers,
> > > > > > Daniel
> > > > > > _______________________________________________
> > > > > > Netatalk-admins mailing list
> > > > > > Net...@li...
> > > > > > https://lists.sourceforge.net/lists/listinfo/netatalk-admins
> > > > > > _______________________________________________
> > > > > > Netatalk-admins mailing list
> > > > > > Net...@li...
> > > > > > https://lists.sourceforge.net/lists/listinfo/netatalk-admins
> > > > > > <signature.asc>

Re: [Netatalk-admins] Removing old documentation from website

[Daniel M. <da...@mi...>]

Thanks for the suggestion. I did this now.

The tarball on SourceForge has been cleaned up!


On Sunday, April 6th, 2025 at 7:18 PM, Andres Valloud <te...@sm...> wrote:

> 

> 

> Here's a suggestion. In here,
> 

> https://netatalk.io/documentation
> 

> under Supplemental Documentation, a link that says something like
> "archived manuals for previous versions".
> 

> Also FYI the tarball has empty directories for 1.5 and 1.6 (other than
> .gitignore files).
> 

> On 4/6/25 1:36 AM, Daniel Markstedt wrote:
> 

> > Do you have a suggestion a good place to host this tarball, so that it can be discovered by anyone who needs it?
> > 

> > If it's a question of retention, we will always have the git history of the Netatalk/netatalk.io repo.
> > You can go back to earlier commits and get any manual that you need.
> > 

> > https://github.com/Netatalk/netatalk.io/tree/main/public
> > 

> > On Saturday, April 5th, 2025 at 11:47 PM, Andres Valloud te...@sm... wrote:
> > > Did you consider a section of old docs tarballed in their current state?
> > > On 4/5/25 2:11 PM, Daniel Markstedt wrote:
> > > > The Netatalk website has been distributing every manual revision since
> > > > 2.0.2 in 2005.
> > > > 20 years later, this has now grown to a massive sprawl of html pages,
> > > > since we're keeping copies of every minor feature release.
> > > > Apart from the massive sprawl, search engines tend to favor the oldest
> > > > versions of these manual pages.
> > > > You consistently get hits on decade-old docs when googling for specific
> > > > netatalk options and components.
> > > > Therefore, I plan to start replacing very old docs with redirects to the
> > > > latest docs.
> > > > Old docs can still be recovered in git revision history, or regenerated
> > > > from docbook sources if needed.
> > > > In phase one, I plan to remove docs for release versions that are
> > > > already EOL: 2.0, 2.1, 2.2, 2.3, 3.0 and 4.0.
> > > > I'm open to suggestions about the ideal end state.
> > > > My preference would be to host a single version of the manual for the
> > > > latest stable version.
> > > > But if people find older manuals useful then we can debate it.
> > 

> > > > Cheers,
> > > > Daniel
> > > > _______________________________________________
> > > > Netatalk-admins mailing list
> > > > Net...@li...
> > > > https://lists.sourceforge.net/lists/listinfo/netatalk-admins

Re: [Netatalk-admins] Removing old documentation from website

[Andres V. <te...@sm...>]

Here's a suggestion.  In here,

https://netatalk.io/documentation

under Supplemental Documentation, a link that says something like 
"archived manuals for previous versions".

Also FYI the tarball has empty directories for 1.5 and 1.6 (other than 
.gitignore files).

On 4/6/25 1:36 AM, Daniel Markstedt wrote:
> Do you have a suggestion a good place to host this tarball, so that it can be discovered by anyone who needs it?
> 
> If it's a question of retention, we will always have the git history of the Netatalk/netatalk.io repo.
> You can go back to earlier commits and get any manual that you need.
> 
> https://github.com/Netatalk/netatalk.io/tree/main/public
> 
> On Saturday, April 5th, 2025 at 11:47 PM, Andres Valloud <te...@sm...> wrote:
> 
>>
> 
>>
> 
>> Did you consider a section of old docs tarballed in their current state?
>>
> 
>> On 4/5/25 2:11 PM, Daniel Markstedt wrote:
>>
> 
>>> The Netatalk website has been distributing every manual revision since
>>> 2.0.2 in 2005.
>>> 20 years later, this has now grown to a massive sprawl of html pages,
>>> since we're keeping copies of every minor feature release.
>>>
> 
>>> Apart from the massive sprawl, search engines tend to favor the oldest
>>> versions of these manual pages.
>>> You consistently get hits on decade-old docs when googling for specific
>>> netatalk options and components.
>>>
> 
>>> Therefore, I plan to start replacing very old docs with redirects to the
>>> latest docs.
>>> Old docs can still be recovered in git revision history, or regenerated
>>> from docbook sources if needed.
>>>
> 
>>> In phase one, I plan to remove docs for release versions that are
>>> already EOL: 2.0, 2.1, 2.2, 2.3, 3.0 and 4.0.
>>>
> 
>>> I'm open to suggestions about the ideal end state.
>>> My preference would be to host a single version of the manual for the
>>> latest stable version.
>>> But if people find older manuals useful then we can debate it.
>>>
> 
>>> Cheers,
>>>
> 
>>> Daniel
>>>
> 
>>> _______________________________________________
>>> Netatalk-admins mailing list
>>> Net...@li...
>>> https://lists.sourceforge.net/lists/listinfo/netatalk-admins

Re: [Netatalk-admins] Removing old documentation from website

[Daniel M. <da...@mi...>]

I went ahead and tarballed the manual and release notes for netatalk 1.5 through 4.1 and put it on SourceForge.

https://sourceforge.net/projects/netatalk/files/docs/netatalk-docs-1.5-to-4.1.tar.gz/download

While I initially attempted to do surgical redirections for the oldest docs, I quickly ran into Cloudflare free tier limitations (max 10 redirect rules).

So we now have aggressive redirects in place from all older manual URLs to the latest 4.2 manual.
The vast majority of old URLs should still work and take you to the equivalent new page.

Please let me know if you run into any bugs!

On Sunday, April 6th, 2025 at 10:36 AM, Daniel Markstedt <da...@mi...> wrote:

> 

> 

> Do you have a suggestion a good place to host this tarball, so that it can be discovered by anyone who needs it?
> 

> If it's a question of retention, we will always have the git history of the Netatalk/netatalk.io repo.
> You can go back to earlier commits and get any manual that you need.
> 

> https://github.com/Netatalk/netatalk.io/tree/main/public
> 

> On Saturday, April 5th, 2025 at 11:47 PM, Andres Valloud te...@sm... wrote:
> 

> > Did you consider a section of old docs tarballed in their current state?
> 

> > On 4/5/25 2:11 PM, Daniel Markstedt wrote:
> 

> > > The Netatalk website has been distributing every manual revision since
> > > 2.0.2 in 2005.
> > > 20 years later, this has now grown to a massive sprawl of html pages,
> > > since we're keeping copies of every minor feature release.
> 

> > > Apart from the massive sprawl, search engines tend to favor the oldest
> > > versions of these manual pages.
> > > You consistently get hits on decade-old docs when googling for specific
> > > netatalk options and components.
> 

> > > Therefore, I plan to start replacing very old docs with redirects to the
> > > latest docs.
> > > Old docs can still be recovered in git revision history, or regenerated
> > > from docbook sources if needed.
> 

> > > In phase one, I plan to remove docs for release versions that are
> > > already EOL: 2.0, 2.1, 2.2, 2.3, 3.0 and 4.0.
> 

> > > I'm open to suggestions about the ideal end state.
> > > My preference would be to host a single version of the manual for the
> > > latest stable version.
> > > But if people find older manuals useful then we can debate it.
> 

> > > Cheers,
> 

> > > Daniel
> 

> > > _______________________________________________
> > > Netatalk-admins mailing list
> > > Net...@li...
> > > https://lists.sourceforge.net/lists/listinfo/netatalk-admins_______________________________________________
> 

> Netatalk-admins mailing list
> Net...@li...
> https://lists.sourceforge.net/lists/listinfo/netatalk-admins

Re: [Netatalk-admins] Removing old documentation from website

[Daniel M. <da...@mi...>]

Do you have a suggestion a good place to host this tarball, so that it can be discovered by anyone who needs it?

If it's a question of retention, we will always have the git history of the Netatalk/netatalk.io repo.
You can go back to earlier commits and get any manual that you need.

https://github.com/Netatalk/netatalk.io/tree/main/public

On Saturday, April 5th, 2025 at 11:47 PM, Andres Valloud <te...@sm...> wrote:

> 

> 

> Did you consider a section of old docs tarballed in their current state?
> 

> On 4/5/25 2:11 PM, Daniel Markstedt wrote:
> 

> > The Netatalk website has been distributing every manual revision since
> > 2.0.2 in 2005.
> > 20 years later, this has now grown to a massive sprawl of html pages,
> > since we're keeping copies of every minor feature release.
> > 

> > Apart from the massive sprawl, search engines tend to favor the oldest
> > versions of these manual pages.
> > You consistently get hits on decade-old docs when googling for specific
> > netatalk options and components.
> > 

> > Therefore, I plan to start replacing very old docs with redirects to the
> > latest docs.
> > Old docs can still be recovered in git revision history, or regenerated
> > from docbook sources if needed.
> > 

> > In phase one, I plan to remove docs for release versions that are
> > already EOL: 2.0, 2.1, 2.2, 2.3, 3.0 and 4.0.
> > 

> > I'm open to suggestions about the ideal end state.
> > My preference would be to host a single version of the manual for the
> > latest stable version.
> > But if people find older manuals useful then we can debate it.
> > 

> > Cheers,
> > 

> > Daniel
> > 

> > _______________________________________________
> > Netatalk-admins mailing list
> > Net...@li...
> > https://lists.sourceforge.net/lists/listinfo/netatalk-admins

Re: [Netatalk-admins] Removing old documentation from website

[Andres V. <te...@sm...>]

Did you consider a section of old docs tarballed in their current state?

On 4/5/25 2:11 PM, Daniel Markstedt wrote:
> The Netatalk website has been distributing every manual revision since 
> 2.0.2 in 2005.
> 20 years later, this has now grown to a massive sprawl of html pages, 
> since we're keeping copies of every minor feature release.
> 
> Apart from the massive sprawl, search engines tend to favor the oldest 
> versions of these manual pages.
> You consistently get hits on decade-old docs when googling for specific 
> netatalk options and components.
> 
> Therefore, I plan to start replacing very old docs with redirects to the 
> latest docs.
> Old docs can still be recovered in git revision history, or regenerated 
> from docbook sources if needed.
> 
> In phase one, I plan to remove docs for release versions that are 
> already EOL: 2.0, 2.1, 2.2, 2.3, 3.0 and 4.0.
> 
> I'm open to suggestions about the ideal end state.
> My preference would be to host a single version of the manual for the 
> latest stable version.
> But if people find older manuals useful then we can debate it.
> 
> Cheers,
> 
> Daniel
> 
> 
> _______________________________________________
> Netatalk-admins mailing list
> Net...@li...
> https://lists.sourceforge.net/lists/listinfo/netatalk-admins

[Netatalk-admins] Removing old documentation from website

[Daniel M. <da...@mi...>]

The Netatalk website has been distributing every manual revision since 2.0.2 in 2005.
20 years later, this has now grown to a massive sprawl of html pages, since we're keeping copies of every minor feature release.

Apart from the massive sprawl, search engines tend to favor the oldest versions of these manual pages.
You consistently get hits on decade-old docs when googling for specific netatalk options and components.

Therefore, I plan to start replacing very old docs with redirects to the latest docs.
Old docs can still be recovered in git revision history, or regenerated from docbook sources if needed.

In phase one, I plan to remove docs for release versions that are already EOL: 2.0, 2.1, 2.2, 2.3, 3.0 and 4.0.

I'm open to suggestions about the ideal end state.
My preference would be to host a single version of the manual for the latest stable version.
But if people find older manuals useful then we can debate it.

Cheers,

Daniel

Re: [Netatalk-admins] Netatalk 4.2.0

[Daniel M. <da...@mi...>]

Hi Michael,

I agree that there are valid reasons for wanting case-sensitive volume names.
Therefore we have introduced the "volume name" option in this version.
If you set "volume name" to the string that was previously the section ID, you will get the same behavior as previously.

For example:

[my volume]
path = /my/path
volume name = My AFP Volume

The full release notes has some more details and discussion on this, as well.

Cheers,

Daniel

On Tuesday, April 1st, 2025 at 11:27 AM, Michael Grundmann <mi...@li...> wrote:

> 

> 

> Am 31.03.25 um 23:41 schrieb Daniel Markstedt:
> 

> 

> 

> So far, Netatalk has relied on ini section names for volume names.
> However, upstream iniparser treats section names as case insensitive,
> and will force them to lowercase internally. Hence, you will see that by
> default, your volumes are now named in all lowercase. For instance, if
> your volume section is defined as [My AFP Volume] it will be mounted as
> my afp volume on a Mac.
> 

> 

> Hi - I don't know, but I think thats not a good idear - what is whit the
> pathnames of pictures in Indesign-Documents
> 

> /Volumes/My AFP Volume/pictures/1.jpg ≠ /Volumes/my afp
> volume/pictures/1.jpg
> 

> 

> So - I don't know
> 

> 

> > The Netatalk dev team is proud to present the first version in the 4.2 release series.
> > 

> > Find the release notes and tarballs at:
> > https://github.com/Netatalk/netatalk/releases/tag/netatalk-4-2-0
> > 

> > The theme for this release series is security and reliability.
> > 

> > We are now more aggressively controlling and validating the size of buffers, check for NULL pointers, free dynamically allocated memory, initialize variables before use, control filesystem access with file handlers to avoid race conditions, and so on.
> > 

> > For the first time ever, we pass our own Quality Gate on SonarQube.
> > https://sonarcloud.io/summary/overall?id=Netatalk_netatalk&branch=main
> > 

> > While we haven't seen any side effects in our testing, there is a small chance that edge cases are seeing different behavior now, for instance due to C strings being truncated instead of allowed to overflow. If you find new bugs, please report them to us!
> > 

> > There are also two notable dependency changes:
> > 

> > We now depend on a shared iniparser library, rather than the bundled one used since v3.0.
> > This leads to some marginal changes in ini parser behavor, since our local library was heavily modified.
> > However we believe this is a beneficial move in the long run, since iniparser is an actively developed library.
> > 

> > Secondly, we have converted all documentation from XML to Markdown.
> > This removes the dependency on the XML stack and DocBook XSL stylesheets.
> > Rather, we now use cmark to generate man pages from Markdown sources.
> > 

> > Beyond this, there are a large number of quality-of-life improvements and bugfixes in this release.
> > 

> > A big thanks to all contributors!
> > 

> > We are looking forward to your feedback.
> > 

> > Sincerely,
> > 

> > Daniel
> > 

> > _______________________________________________
> > Netatalk-admins mailing list
> > Net...@li...
> > https://lists.sourceforge.net/lists/listinfo/netatalk-admins
> 

> 

> 

> --
> Gruß Michael
> 

> Wenn du verstehst, was du tust, wirst du nichts lernen
> 

> 

> _______________________________________________
> Netatalk-admins mailing list
> Net...@li...
> https://lists.sourceforge.net/lists/listinfo/netatalk-admins

Re: [Netatalk-admins] Netatalk 4.2.0

[Michael G. <mi...@li...>]

Am 31.03.25 um 23:41 schrieb Daniel Markstedt:



So far, Netatalk has relied on ini section names for volume names. 
However, upstream iniparser treats section names as case insensitive, 
and will force them to lowercase internally. Hence, you will see that by 
default, your volumes are now named in all lowercase. For instance, if 
your volume section is defined as [My AFP Volume] it will be mounted as 
my afp volume on a Mac.


Hi - I don't know, but I think thats not a good idear - what is whit the 
pathnames of pictures in Indesign-Documents

/Volumes/My AFP Volume/pictures/1.jpg ≠ /Volumes/my afp 
volume/pictures/1.jpg


So - I don't know


> The Netatalk dev team is proud to present the first version in the 4.2 release series.
> 
> Find the release notes and tarballs at:
> https://github.com/Netatalk/netatalk/releases/tag/netatalk-4-2-0
> 
> The theme for this release series is security and reliability.
> 
> We are now more aggressively controlling and validating the size of buffers, check for NULL pointers, free dynamically allocated memory, initialize variables before use, control filesystem access with file handlers to avoid race conditions, and so on.
> 
> For the first time ever, we pass our own Quality Gate on SonarQube.
> https://sonarcloud.io/summary/overall?id=Netatalk_netatalk&branch=main
> 
> While we haven't seen any side effects in our testing, there is a small chance that edge cases are seeing different behavior now, for instance due to C strings being truncated instead of allowed to overflow. If you find new bugs, please report them to us!
> 
> There are also two notable dependency changes:
> 
> We now depend on a shared iniparser library, rather than the bundled one used since v3.0.
> This leads to some marginal changes in ini parser behavor, since our local library was heavily modified.
> However we believe this is a beneficial move in the long run, since iniparser is an actively developed library.
> 
> Secondly, we have converted all documentation from XML to Markdown.
> This removes the dependency on the XML stack and DocBook XSL stylesheets.
> Rather, we now use cmark to generate man pages from Markdown sources.
> 
> Beyond this, there are a large number of quality-of-life improvements and bugfixes in this release.
> 
> A big thanks to all contributors!
> 
> We are looking forward to your feedback.
> 
> Sincerely,
> 
> Daniel
> 
> 
> 
> _______________________________________________
> Netatalk-admins mailing list
> Net...@li...
> https://lists.sourceforge.net/lists/listinfo/netatalk-admins


-- 
Gruß Michael

Wenn du verstehst, was du tust, wirst du nichts lernen

[Netatalk-admins] Netatalk 4.2.0

[Daniel M. <da...@mi...>]

The Netatalk dev team is proud to present the first version in the 4.2 release series.

Find the release notes and tarballs at:
https://github.com/Netatalk/netatalk/releases/tag/netatalk-4-2-0

The theme for this release series is security and reliability.

We are now more aggressively controlling and validating the size of buffers, check for NULL pointers, free dynamically allocated memory, initialize variables before use, control filesystem access with file handlers to avoid race conditions, and so on.

For the first time ever, we pass our own Quality Gate on SonarQube.
https://sonarcloud.io/summary/overall?id=Netatalk_netatalk&branch=main

While we haven't seen any side effects in our testing, there is a small chance that edge cases are seeing different behavior now, for instance due to C strings being truncated instead of allowed to overflow. If you find new bugs, please report them to us!

There are also two notable dependency changes:

We now depend on a shared iniparser library, rather than the bundled one used since v3.0.
This leads to some marginal changes in ini parser behavor, since our local library was heavily modified.
However we believe this is a beneficial move in the long run, since iniparser is an actively developed library.

Secondly, we have converted all documentation from XML to Markdown.
This removes the dependency on the XML stack and DocBook XSL stylesheets.
Rather, we now use cmark to generate man pages from Markdown sources.

Beyond this, there are a large number of quality-of-life improvements and bugfixes in this release.

A big thanks to all contributors!

We are looking forward to your feedback.

Sincerely,

Daniel

Re: [Netatalk-admins] Would you miss the "include" directive in afp.conf?

[Daniel M. <da...@mi...>]

Hi Andres,

It's not a bad idea. This was actually what I tried to implement first, a few weeks ago. However there is logic for stating and polling for changes in both afp.conf and the "include" secondary conf file, with some extra sanity checking that they're valid ini files that can be read.

So when I tried to add support for an arbitrary number of config files, it got very complex very fast.

Little known fact (probably) is that afp.conf and its daughter file gets read at least 6 times only when netatalk starts up, and then again as users connect. This is because all four daemons: netatalk, afpd, cnid_metad and cnid_dbd read settings from this config file at various stages through sometimes-hard-to-follow spaghetti code. This is when I miss OOP. ;)

Cheers!

Daniel

On Sunday, March 30th, 2025 at 10:29 AM, Andres Valloud <te...@sm...> wrote:

> 

> 

> Perhaps --with-config-files=comma,separated,priority,left,to,right.
> 

> Side comment only.
> 

> On 3/30/25 12:30 AM, Daniel Markstedt wrote:
> 

> > Hi Chris,
> > 

> > Thanks for sharing your use case. This is a valuable insight regardless
> > of whether the product you worked on still supports netatalk or not.
> > 

> > This makes me imagine a potential alternative solution: The netatalk
> > daemon (and child daemons) currently take the -F option for a custom
> > path to afp.conf. What if we introduce a, say, -G option for passing the
> > path to the secondary afp.conf. This would theoretically satisfy your
> > use case of having a secondary set of per-user settings.
> > 

> > The main drawback I could see right now, would be that you lose the
> > flexibility of choosing where exactly in the main afp.conf to "inject"
> > the contents of the secondary afp.conf. Rather, the two would always be
> > read and parsed sequentially.
> > 

> > But the code would be a lot simpler and less error prone, IMO.
> > 

> > Thoughts?
> > 

> > Daniel
> > 

> > On Wednesday, March 26th, 2025 at 8:41 PM, Chris Devers
> > cd...@ed... wrote:
> > 

> > > Hello,
> > > 

> > > My employer used to provide AFP support with our storage products, and
> > > when we did, we made use of a mechanism that generated per-user config
> > > files that made use of `include` directives so that we could provide a
> > > mix of global and per-user settings.
> > > 

> > > It’s not really worth getting into implementation specifics though,
> > > because we dropped Netatalk/AFP support a while ago, so this is
> > > academic now. Removing that option would have been a big complication
> > > for us before that, but not now.
> > > 

> > > Not sure if any other storage vendors are still producing systems that
> > > support AFP access to shared storage, per-user configurations. If so,
> > > apparently they aren’t on this mailing list. :-)
> > > 

> > > On Fri, Mar 21, 2025 at 2:34 AM Daniel Markstedt <da...@mi...
> > > mailto:da...@mi...> wrote:
> > > 

> > > Thanks for the feedback, Andres. :)
> > > 

> > > Let me cc the mailing list back, for posterity.
> > > 

> > > I have asked the same question on multiple forums and on Mastodon.
> > > So far a single person has said they use it.
> > > 

> > > Cheers,
> > > Daniel
> > > 

> > > On Sunday, March 16th, 2025 at 11:47 AM, Andres Valloud
> > > <te...@sm... mailto:te...@sm...> wrote:
> > > 

> > > >
> > > 

> > > >
> > > 

> > > > Won't miss :).
> > > >
> > > 

> > > > On 3/16/25 3:09 AM, Daniel Markstedt wrote:
> > > >
> > > 

> > > > > Dear Netatalk community,
> > > > >
> > > 

> > > > > Would you be negatively impacted if we were to remove support
> > > for the
> > > > > "include" directive in afp.conf?
> > > > >
> > > 

> > > > > As a refresher, "include = /path/to/extra_afp.conf" allows you to
> > > > > dynamically load a secondary ini file that gets nested inside
> > > of the
> > > > > main afp.conf file.
> > > > >
> > > 

> > > > > In the main development branch, we have removed the vendored
> > > iniparser
> > > > > library in favor of linking with the shared system iniparser
> > > library.
> > > > > Our vendored iniparser library contained multiple hacks,
> > > notably support
> > > > > for the "include" directive.
> > > > >
> > > 

> > > > > There are other ways to achieve similar outcomes, for instance
> > > > > concatenating multiple ini files into a combined afp.conf temp
> > > file that
> > > > > then gets read by iniparser.
> > > > > However, there's a bunch of logic internally for error
> > > handling and
> > > > > polling for modified time stamps on the ini files that
> > > complicate any
> > > > > solution.
> > > > > I'd personally prefer to drop "include" to reduce complexity
> > > and reduce
> > > > > the risk of bugs.
> > > > >
> > > 

> > > > > I'm looking forward to hear back from you. :)
> > > > >
> > > 

> > > > > Daniel
> > > > >
> > > 

> > > > > _______________________________________________
> > > > > Netatalk-admins mailing list
> > > > > Net...@li... <mailto:Netatalk-
> > > ad...@li...>
> > > > > https://lists.sourceforge.net/lists/listinfo/netatalk-admins
> > > <https://lists.sourceforge.net/lists/listinfo/netatalk-
> > > admins>_______________________________________________
> > > Netatalk-admins mailing list
> > > Net...@li... <mailto:Netatalk-
> > > ad...@li...>
> > > https://lists.sourceforge.net/lists/listinfo/netatalk-admins
> > > https://lists.sourceforge.net/lists/listinfo/netatalk-admins
> > 

> > _______________________________________________
> > Netatalk-admins mailing list
> > Net...@li...
> > https://lists.sourceforge.net/lists/listinfo/netatalk-admins

Re: [Netatalk-admins] Would you miss the "include" directive in afp.conf?

[Andres V. <te...@sm...>]

Perhaps --with-config-files=comma,separated,priority,left,to,right.

Side comment only.

On 3/30/25 12:30 AM, Daniel Markstedt wrote:
> Hi Chris,
> 
> Thanks for sharing your use case. This is a valuable insight regardless 
> of whether the product you worked on still supports netatalk or not.
> 
> This makes me imagine a potential alternative solution: The netatalk 
> daemon (and child daemons) currently take the -F option for a custom 
> path to afp.conf. What if we introduce a, say, -G option for passing the 
> path to the secondary afp.conf. This would theoretically satisfy your 
> use case of having a secondary set of per-user settings.
> 
> The main drawback I could see right now, would be that you lose the 
> flexibility of choosing where exactly in the main afp.conf to "inject" 
> the contents of the secondary afp.conf. Rather, the two would always be 
> read and parsed sequentially.
> 
> But the code would be a lot simpler and less error prone, IMO.
> 
> Thoughts?
> 
> Daniel
> 
> On Wednesday, March 26th, 2025 at 8:41 PM, Chris Devers 
> <cd...@ed...> wrote:
>> Hello,
>>
>> My employer used to provide AFP support with our storage products, and 
>> when we did, we made use of a mechanism that generated per-user config 
>> files that made use of `include` directives so that we could provide a 
>> mix of global and per-user settings.
>>
>> It’s not really worth getting into implementation specifics though, 
>> because we dropped Netatalk/AFP support a while ago, so this is 
>> academic now. Removing that option would have been a big complication 
>> for us before that, but not now.
>>
>> Not sure if any other storage vendors are still producing systems that 
>> support AFP access to shared storage, per-user configurations. If so, 
>> apparently they aren’t on this mailing list. :-)
>>
>>
>> On Fri, Mar 21, 2025 at 2:34 AM Daniel Markstedt <da...@mi... 
>> <mailto:da...@mi...>> wrote:
>>
>>     Thanks for the feedback, Andres. :)
>>
>>     Let me cc the mailing list back, for posterity.
>>
>>     I have asked the same question on multiple forums and on Mastodon.
>>     So far a single person has said they use it.
>>
>>     Cheers,
>>     Daniel
>>
>>
>>     On Sunday, March 16th, 2025 at 11:47 AM, Andres Valloud
>>     <te...@sm... <mailto:te...@sm...>> wrote:
>>
>>     >
>>
>>     >
>>
>>     > Won't miss :).
>>     >
>>
>>     > On 3/16/25 3:09 AM, Daniel Markstedt wrote:
>>     >
>>
>>     > > Dear Netatalk community,
>>     > >
>>
>>     > > Would you be negatively impacted if we were to remove support
>>     for the
>>     > > "include" directive in afp.conf?
>>     > >
>>
>>     > > As a refresher, "include = /path/to/extra_afp.conf" allows you to
>>     > > dynamically load a secondary ini file that gets nested inside
>>     of the
>>     > > main afp.conf file.
>>     > >
>>
>>     > > In the main development branch, we have removed the vendored
>>     iniparser
>>     > > library in favor of linking with the shared system iniparser
>>     library.
>>     > > Our vendored iniparser library contained multiple hacks,
>>     notably support
>>     > > for the "include" directive.
>>     > >
>>
>>     > > There are other ways to achieve similar outcomes, for instance
>>     > > concatenating multiple ini files into a combined afp.conf temp
>>     file that
>>     > > then gets read by iniparser.
>>     > > However, there's a bunch of logic internally for error
>>     handling and
>>     > > polling for modified time stamps on the ini files that
>>     complicate any
>>     > > solution.
>>     > > I'd personally prefer to drop "include" to reduce complexity
>>     and reduce
>>     > > the risk of bugs.
>>     > >
>>
>>     > > I'm looking forward to hear back from you. :)
>>     > >
>>
>>     > > Daniel
>>     > >
>>
>>     > > _______________________________________________
>>     > > Netatalk-admins mailing list
>>     > > Net...@li... <mailto:Netatalk-
>>     ad...@li...>
>>     > > https://lists.sourceforge.net/lists/listinfo/netatalk-admins
>>     <https://lists.sourceforge.net/lists/listinfo/netatalk-
>>     admins>_______________________________________________
>>     Netatalk-admins mailing list
>>     Net...@li... <mailto:Netatalk-
>>     ad...@li...>
>>     https://lists.sourceforge.net/lists/listinfo/netatalk-admins
>>     <https://lists.sourceforge.net/lists/listinfo/netatalk-admins>
>>
> 
> 
> 
> _______________________________________________
> Netatalk-admins mailing list
> Net...@li...
> https://lists.sourceforge.net/lists/listinfo/netatalk-admins

Re: [Netatalk-admins] Would you miss the "include" directive in afp.conf?

[Daniel M. <da...@mi...>]

Hi Chris,

Thanks for sharing your use case. This is a valuable insight regardless of whether the product you worked on still supports netatalk or not.

This makes me imagine a potential alternative solution: The netatalk daemon (and child daemons) currently take the -F option for a custom path to afp.conf. What if we introduce a, say, -G option for passing the path to the secondary afp.conf. This would theoretically satisfy your use case of having a secondary set of per-user settings.

The main drawback I could see right now, would be that you lose the flexibility of choosing where exactly in the main afp.conf to "inject" the contents of the secondary afp.conf. Rather, the two would always be read and parsed sequentially.

But the code would be a lot simpler and less error prone, IMO.

Thoughts?

Daniel


On Wednesday, March 26th, 2025 at 8:41 PM, Chris Devers <cd...@ed...> wrote:

> Hello,
> 

> My employer used to provide AFP support with our storage products, and when we did, we made use of a mechanism that generated per-user config files that made use of `include` directives so that we could provide a mix of global and per-user settings.
> 

> It’s not really worth getting into implementation specifics though, because we dropped Netatalk/AFP support a while ago, so this is academic now. Removing that option would have been a big complication for us before that, but not now.
> 

> Not sure if any other storage vendors are still producing systems that support AFP access to shared storage, per-user configurations. If so, apparently they aren’t on this mailing list. :-)
> 

> 

> On Fri, Mar 21, 2025 at 2:34 AM Daniel Markstedt <da...@mi...> wrote:
> 

> > Thanks for the feedback, Andres. :)
> > 

> > Let me cc the mailing list back, for posterity.
> > 

> > I have asked the same question on multiple forums and on Mastodon. So far a single person has said they use it.
> > 

> > Cheers,
> > Daniel
> > 

> > 

> > On Sunday, March 16th, 2025 at 11:47 AM, Andres Valloud <te...@sm...> wrote:
> > 

> > >
> > 

> > >
> > 

> > > Won't miss :).
> > >
> > 

> > > On 3/16/25 3:09 AM, Daniel Markstedt wrote:
> > >
> > 

> > > > Dear Netatalk community,
> > > >
> > 

> > > > Would you be negatively impacted if we were to remove support for the
> > > > "include" directive in afp.conf?
> > > >
> > 

> > > > As a refresher, "include = /path/to/extra_afp.conf" allows you to
> > > > dynamically load a secondary ini file that gets nested inside of the
> > > > main afp.conf file.
> > > >
> > 

> > > > In the main development branch, we have removed the vendored iniparser
> > > > library in favor of linking with the shared system iniparser library.
> > > > Our vendored iniparser library contained multiple hacks, notably support
> > > > for the "include" directive.
> > > >
> > 

> > > > There are other ways to achieve similar outcomes, for instance
> > > > concatenating multiple ini files into a combined afp.conf temp file that
> > > > then gets read by iniparser.
> > > > However, there's a bunch of logic internally for error handling and
> > > > polling for modified time stamps on the ini files that complicate any
> > > > solution.
> > > > I'd personally prefer to drop "include" to reduce complexity and reduce
> > > > the risk of bugs.
> > > >
> > 

> > > > I'm looking forward to hear back from you. :)
> > > >
> > 

> > > > Daniel
> > > >
> > 

> > > > _______________________________________________
> > > > Netatalk-admins mailing list
> > > > Net...@li...
> > > > https://lists.sourceforge.net/lists/listinfo/netatalk-admins_______________________________________________
> > Netatalk-admins mailing list
> > Net...@li...
> > https://lists.sourceforge.net/lists/listinfo/netatalk-admins