Initial directory entry on the server:
First-Mini% ls -la Accounts.xlsx
-rw-rw-r--@ 1 root admin 15211 21 Mar 2016 Accounts.xlsx
Entry after Excel has saved the file:
First-Mini% ls -la Accounts.xlsx
-rw-------@ 1 tim admin 15623 14 Dec 21:53 Accounts.xlsx
Worth adding that all I did was open the file and save it - no changes >attempted. So WTF is Excel doing with dorking over the permissions and >changing the file ownership?
In article <jvv2aqF2ptiU1@mid.individual.net>,
TimS <timstreater@greenbee.net> wrote:
Initial directory entry on the server:
First-Mini% ls -la Accounts.xlsx
-rw-rw-r--@ 1 root admin 15211 21 Mar 2016 Accounts.xlsx
Entry after Excel has saved the file:
First-Mini% ls -la Accounts.xlsx
-rw-------@ 1 tim admin 15623 14 Dec 21:53 Accounts.xlsx
Worth adding that all I did was open the file and save it - no changes
attempted. So WTF is Excel doing with dorking over the permissions and
changing the file ownership?
This is just conjecture: quite likely it doesn't overwrite the
existing file (because if it did that and an error occurred the file
would be lost), but instead creates a new file leaving the original
intact until it has finished writing. In that case it can't create a
file owned by root.
As for the permissions, the normal unix way is to obey your umask, but
I doubt Excel works like that.
We tend to be sent accounts spreadsheets and similar, and just leave
them on our server, usually never to be looked at. Today however
SWMBO and I needed to work, sequentially, on the same spreadsheet she
had copied to the server. We both have the server volume mounted, so
she went ahead and edited it, save, and quit Excel. We're each
running Office 2016 on our own machine, the file(s) in question are
on a volume on our file server, on the same LAN.
After that I could only open it read-only onb my machine so after I'd
also finished I saved it locally and copied it back to the server.
Looks like Excel does this sort of stuff:
Initial directory entry on the server:
First-Mini% ls -la Accounts.xlsx -rw-rw-r--@ 1 root admin 15211 21
Mar 2016 Accounts.xlsx
Entry after Excel has saved the file:
First-Mini% ls -la Accounts.xlsx -rw-------@ 1 tim admin 15623 14
Dec 21:53 Accounts.xlsx
Worth adding that all I did was open the file and save it - no
changes attempted. So WTF is Excel doing with dorking over the
permissions and changing the file ownership?
Also worth noting that I tried the same with a text file, using
BBEdit. And it saved the file back on the server, leaving the owner/permissions untouched.
I'm running Mojave on a 2018 Mini, SWMBO is Big Sur on an M1 Mini,
the server is a 2014 Mini running Mojave. All on the local LAN.
Googling for this gave a thread where some MS people responded to a
number of folks with the issue, mostly telling them, AFAICS, to
upgrade this, that, and the other. Someone appeared to have had
success by moving from Mojave to Catalina, so I might try that. But
SWMBO is, in any case, on Big Sur.
On 14/12/2022 22:51, TimS wrote:
We tend to be sent accounts spreadsheets and similar, and just leave
them on our server, usually never to be looked at. Today however
SWMBO and I needed to work, sequentially, on the same spreadsheet she
had copied to the server. We both have the server volume mounted, so
she went ahead and edited it, save, and quit Excel. We're each
running Office 2016 on our own machine, the file(s) in question are
on a volume on our file server, on the same LAN.
After that I could only open it read-only onb my machine so after I'd
also finished I saved it locally and copied it back to the server.
Looks like Excel does this sort of stuff:
Initial directory entry on the server:
First-Mini% ls -la Accounts.xlsx -rw-rw-r--@ 1 root admin 15211 21
Mar 2016 Accounts.xlsx
What does 'ls -le' show? You might have some overriding access control
list permissions coming into play.
Worth adding that all I did was open the file and save it - no
changes attempted. So WTF is Excel doing with dorking over the
permissions and changing the file ownership?
Excel considers even trivial things like moving the highlighted cell to
be a change. Since you saved the file, Excel replaces the old one with a
new file (done in a safe way in case there is a crash mid-save, so
typically: create tmp file; delete old file; rename tmp file to back to
the original name.)
Upshot is that there is a new file with file permissions based on your defaults.
Also worth noting that I tried the same with a text file, using
BBEdit. And it saved the file back on the server, leaving the
owner/permissions untouched.
When you say "I tried" do you mean that you got SWMBO to save a text
file on the server? And did the file have the same initial permissions
as the Excel one before you tried editing it in BBEdit?
On 16 Dec 2022 at 17:38:13 GMT, "Bruce Horrocks" <07.013@scorecrow.com> wrote:
On 14/12/2022 22:51, TimS wrote:
We tend to be sent accounts spreadsheets and similar, and just leave
them on our server, usually never to be looked at. Today however
SWMBO and I needed to work, sequentially, on the same spreadsheet she
had copied to the server. We both have the server volume mounted, so
she went ahead and edited it, save, and quit Excel. We're each
running Office 2016 on our own machine, the file(s) in question are
on a volume on our file server, on the same LAN.
After that I could only open it read-only onb my machine so after I'd
also finished I saved it locally and copied it back to the server.
Looks like Excel does this sort of stuff:
Initial directory entry on the server:
First-Mini% ls -la Accounts.xlsx -rw-rw-r--@ 1 root admin 15211 21
Mar 2016 Accounts.xlsx
What does 'ls -le' show? You might have some overriding access control
list permissions coming into play.
No different to:
ls -la filename
There is always the @ at the end of the permissions, though.
Worth adding that all I did was open the file and save it - no
changes attempted. So WTF is Excel doing with dorking over the
permissions and changing the file ownership?
Excel considers even trivial things like moving the highlighted cell to
be a change. Since you saved the file, Excel replaces the old one with a
new file (done in a safe way in case there is a crash mid-save, so
typically: create tmp file; delete old file; rename tmp file to back to
the original name.)
Upshot is that there is a new file with file permissions based on your
defaults.
Yerss, that makes sense. Interesting that Word only changes the file owner, not the group permissions, whereas Excel removes group-write permission too.
Also worth noting that I tried the same with a text file, using
BBEdit. And it saved the file back on the server, leaving the
owner/permissions untouched.
When you say "I tried" do you mean that you got SWMBO to save a text
file on the server? And did the file have the same initial permissions
as the Excel one before you tried editing it in BBEdit?
No, I looked in the folder on the server for a text file, opened it on my machine in BBEdit, added and then removed a blank char and saved the file. Which BBEdit did, back to the server, without changing owner or permissions at
all.
Since then I updated the server to Catalina. This exposed a really bad bug in file sharing after I'd installed the final Apple security updates for Catalina: if file sharing is on/off, you can turn it off/on by clicking the tick-box, but thereafter you are unable to change the state of file sharing again. Clicks to the tick-box are ignored. A quick giggle and it transpired tons of people on the Apple Discussion forum were moaning about this - the work around involved doing some launchctl load/unload stuff, which, after I did it, allowed me to change the state of file sharing.
However it felt unwise to leave it there so I updated to Monterey which fixed this bug, no change in the Excel situation, obvs.
One more thing I've tried without success in both Mojave and Monterey. Dunno if it's a bug or something else I need to do. In the File Sharing pane on the server I select the volume I'm sharing (in the shared folders subpane). Then in the users subpane I click the + and add myself and SWMBO, and give both of us read/write access. That should do it, one might think. And I can move to some other item in System Preferences and back to sharing, and we're both still there. But the moment I close System Prefs, and re-open it, those settings I just added are gone - they don't stick. No idea why.
Meanwhile, on the server, I've done what feels like a hacky workaround - in Get Info on the volume being shared, I've ticked "Ignore ownership on this volume" which overrides what Excel does. But that feels unsafe. Comments?
On 16/12/2022 23:06, TimS wrote:
On 16 Dec 2022 at 17:38:13 GMT, "Bruce Horrocks" <07.013@scorecrow.com> wrote:
On 14/12/2022 22:51, TimS wrote:
We tend to be sent accounts spreadsheets and similar, and just leave them on our server, usually never to be looked at. Today however
SWMBO and I needed to work, sequentially, on the same spreadsheet she had copied to the server. We both have the server volume mounted, so she went ahead and edited it, save, and quit Excel. We're each
running Office 2016 on our own machine, the file(s) in question are
on a volume on our file server, on the same LAN.
After that I could only open it read-only onb my machine so after I'd also finished I saved it locally and copied it back to the server. Looks like Excel does this sort of stuff:
Initial directory entry on the server:
First-Mini% ls -la Accounts.xlsx -rw-rw-r--@ 1 root admin 15211 21
Mar 2016 Accounts.xlsx
What does 'ls -le' show? You might have some overriding access control list permissions coming into play.
No different to:
ls -la filename
There is always the @ at the end of the permissions, though.
That's just extended attributes. You can use the 'xattr' command from Terminal to see what the extra attributes are. usually it's things like
where the file was originally downloaded from.
Worth adding that all I did was open the file and save it - no
changes attempted. So WTF is Excel doing with dorking over the permissions and changing the file ownership?
Excel considers even trivial things like moving the highlighted cell to be a change. Since you saved the file, Excel replaces the old one with a new file (done in a safe way in case there is a crash mid-save, so typically: create tmp file; delete old file; rename tmp file to back to the original name.)
Upshot is that there is a new file with file permissions based on your defaults.
Yerss, that makes sense. Interesting that Word only changes the file owner, not the group permissions, whereas Excel removes group-write permission too.
Excel was developed by a different company and bought by Microsoft so
it's not surprising that it and Word behave differently.
On Dec 19, 2022, Bruce Horrocks wrote
(in article<49174a18-f24e-8e13-5c1e-47a0089cf666@scorecrow.com>):
Excel was developed by a different company and bought by Microsoft so
it's not surprising that it and Word behave differently.
No, that’s wrong. Excel is 100% Microsoft.
On 20/12/2022 06:21, WolfFan wrote:
On Dec 19, 2022, Bruce Horrocks wrote
(in article<49174a18-f24e-8e13-5c1e-47a0089cf666@scorecrow.com>):
Excel was developed by a different company and bought by Microsoft so
it's not surprising that it and Word behave differently.
No, that’s wrong. Excel is 100% Microsoft.
Spot on - Excel was originally developed by MS for the Mac.
Word used to have something called "fast save" which probably just
appends to the existing file instead of writing a new file and doing the rename dance.
On 20/12/2022 09:52, Chris Ridd wrote:
On 20/12/2022 06:21, WolfFan wrote:
On Dec 19, 2022, Bruce Horrocks wrote
(in article<49174a18-f24e-8e13-5c1e-47a0089cf666@scorecrow.com>):
Excel was developed by a different company and bought by Microsoft so it's not surprising that it and Word behave differently.
No, that’s wrong. Excel is 100% Microsoft.
Spot on - Excel was originally developed by MS for the Mac.
Word used to have something called "fast save" which probably just
appends to the existing file instead of writing a new file and doing the rename dance.
I believe Excel was developed from VisiCalc, which IIRC Gates bought
from the developer about $50k.
When Lotus brought out their spreadsheet on Macs, Jazz, it
was six times the price of Multiplan, and required a Fat Mac, minimum, and had ¹special¹ 401 kB floppies, which were uncopyable. Except that
CopyIIMac could copy them. (Jazz also stunk.)
People bought Macs just to run Excel.
Word and PowerPoint were apps developed by non-MS guys and, umm,
Œacquired¹ by the Bill. All current versions of Word are descended from
Word for Mac 1.0.5, from 1985.
Word was vastly superior to
MacWrite.every file.
No, that’s wrong. Excel is 100% Microsoft.[snip]
In The Beginning (that is, 1984), there was the Mighty Mac 128, and the Steve saw that is was good. And the Bill saw new markets. And lo! The Bill saw that there was a need for a spreadsheet app which worked with the Mighty Mac 128, and knew that Microsgt had bropught forth to an uncaring world a spreadsheet in 1982: Multiplan. Multiplan did not set the world on fire. Multiplan did not even manage to warm a tea kettle. But Multiplan was what the Bill had, so he got a Mac version created and delivered, complete with lame copy-protection, easily defeated by CopyIIMac. Guess how I know. MS wanted users to pay an additional $10 to get a ’spare’ floppy. I didn’t feel like paying extra. When Lotus brought out their spreadsheet on Macs, Jazz, it was six times the price of Multiplan, and required a Fat Mac, minimum, and had ’special’ 401 kB floppies, which were uncopyable. Except that CopyIIMac could copy them. (Jazz also stunk.) MS also brought out Chart, which created lame chartsand graphs, and cost the same $100 that Multiplan did, and was also copy-protected in a way that CopyIIMac completely ignored.
In 1985 MS combined Multiplan and Chart into one app, greatly improved both the spreadsheet and the charting functions, raised the price to $250, required a Fat Mac, dropped the copy protection, and called it Excel. And a legend was born. Excel was an all-Mac app, built by MS, and only MS. And the Bill saw that this was good, for it unleashed rivers of cash into MS’s coffers and as it was all-MS the Bill didn’t have to pay anyone any of that cash. Verily, Excel on a Fat Mac, or, better still, a Mac Plus, was a killer app. People bought Macs just to run Excel. The Bill attempted to repeat his success with Windows; Windows 1 stunk. Windows 2 stunk worse. Those who
complain about Windows Vista or Windows ME have no idea just how superior they were to Win 2. (MS Bob was worse than Win 2, but then it’s hard to get worse than that. The only reason why the project manager in charge of Bob didn’t get fired was that she was married to the Bill.) Windows 3 finally was worth working with; Excel became a killer app there, too. Excel still behaves in some ways like a Mac app; for example, you can close all windows in it and the app itself won’t close, that being a Mac trait for a very long time, now routinely violated.
Word and PowerPoint were apps developed by non-MS guys and, umm, ‘acquired’ by the Bill. All current versions of Word are descended from Word for Mac 1.0.5, from 1985. All current versions of Word behave. Like old-school Mac apps in some ways, still, nearly 40 years later. PowerPoint was a Mac app before the Bill saw it, lust after it, and got it.
Note that in those far-off days a long time ago in a galaxy far, far away (MS was Apple’s sometimes ally against the vast, cold, monster that was IBM, how things have changed) I had Excel and Word first on floppies and then when I got a Mac Plus my external SCSI drive. Word was vastly superior to MacWrite.every file.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 50:19:04 |
| Calls: | 10,397 |
| Calls today: | 5 |
| Files: | 14,067 |
| Messages: | 6,417,315 |
| Posted today: | 1 |