nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

As we transition to the new Hyland Community, some post links may be temporarily disrupted as we finalize redirects. We apologize for the inconvenience and are working to resolve this as quickly as possible. Details.

smbmount destroys metadata

simon

Alf,

We have a space with versioning applied. Add an HTML document and edit it a few times so that we have a couple versions of this file. No problems so far.

Now, open this file with smbmount on UNIX and edit it with vi. Save the file and check the properties in Alfresco, everything is gone: no more versioning, no more description, inline edit disabled,…

Tested this in 1.4.3 and 2.1, both the Enterprise versions, same behavior.

When I open the file in vi it tels me "[noeol]" (no end of line), don't know if this has anything to do with it or not.

When I do

echo "some text" > myfile.html‍

the contents are written and the properties are kept so this seems to work but vi doesn't.

Thanks!

Find more posts tagged with

Comments

simon

*bump*

wabson

Hi Simon,

This sounds like the same problem which can occur when Alfresco is mounted using GNOME-VFS or Mac OS. The issue here is that the OS doesn't simply update the existing file upon a save, but instead creates a new file and deletes the old one.

You can check if this is what is happening with vi by looking in your Deleted Items list via your user preferences in the Alfresco Web Client - you should see all the old versions of the file there.

If this is the case then Alfresco is actually doing the correct thing as it has no way of knowing that the metadata should be copied over onto the new node. Getting round it would require some additional logic, or possibly reconfiguring vi.

Thanks,
Will.

loftux

That is most likely because vi doesn't open the file with a file lock. It opens the file and then creates a completely new file as the working copy. When saving and closing, it is this new file that is kept, and the original is deleted.
So for Alfresco this is a completely new file.

Other applications like MS Word is actually keeping a file lock, and when you are saving and closing, the edits are merged into the original file.

So in order to use vi, try to do a checkout. There still may be a problem as you will loose the association between the original and working copy because of the behavior above.

Peter LÃƒÂ¶fgren

simon

Indeed, as vi is open you see a .filename.swp file and even a file with a number as name during saving. It's also impossible to get the md5 checksum from the file after you saved it with vi.

Yes, it's vi related and I understand it's not easy for Alfresco to solve this but it's the Alfresco "filesystem" or repository that's partly the cause of this. If you do this on a UNIX filesystem this isn't a problem so it's a little easy to say it's vi's "fault", it's the combination of both.

So, it would be nice if Alfresco could solve this, or if there is way to prevent programs that destroy these files in some way. People use vi, they don't know it destroys the metadata and without knowing everything is gone… forever. Any idea how to prevent this?

Having a file repository that is interface independent is one of Alfresco strongest points but I have the feeling these interfaces are not always as equal as I would like them to be.

rdanner

Indeed, as vi is open you see a .filename.swp file and even a file with a number as name during saving. It's also impossible to get the md5 checksum from the file after you saved it with vi.

Yes, it's vi related and I understand it's not easy for Alfresco to solve this but it's the Alfresco "filesystem" or repository that's partly the cause of this. If you do this on a UNIX filesystem this isn't a problem so it's a little easy to say it's vi's "fault", it's the combination of both.

So, it would be nice if Alfresco could solve this, or if there is way to prevent programs that destroy these files in some way. People use vi, they don't know it destroys the metadata and without knowing everything is gone… forever. Any idea how to prevent this?

Having a file repository that is interface independent is one of Alfresco strongest points but I have the feeling these interfaces are not always as equal as I would like them to be.

It's an interesting thought. If there was to be a repository response to this it would have to be a setting – VI does what it does. Alfresco CIFS is a projection of the REPO that is meant to act like a file system. Consider that it is also annoying when you copy a folder from alfresco that you get the executables along with your copy…

I can see the desire for both behaviors – act like a file system – or act like a repo and control this darn artifact – your not a dumb file system, that's the point.

The same can be said for handling the annoying metadata files from MSWindows and mac os (.DS_Store) Can I tell alfresco to ignore these things.. send them to dev/null? I'd like to see a setting.

It's open source, we're free to fix it if we wish

Maybe Gary can chime in here and give us some advice.

simon

Alfresco, any comment on this? Is this something your guys would like to solve in the future or should I try to ban vi out of the company?

simon

Answer from Alfresco:

Our assumption is that Vi works by creating a temp file for the new edits, then renames it on save. We do deal with this scenario for other applications, so it may be possible to put the same behaviour for Vi. This has to be explicitly programmed for each application. This is the first time that Vi has been requested.

simon

Same problem for gedit…

gary_spencer

There is code in the Alfresco filesystem to handle MS Word files as it does a rename shuffle to get the new version of the file in place. This was deliberately coded so it only worked with MS Word files to avoid any side effects with other file save patterns.

The problem is coming up with a generic solution that does not cause side effects. I need to do some more research on this with vi and other editors, not sure when I will get around to that with the current work load.

Gary

xerox

Garry,

thanks for you answer.

I think this problem needs enough prioritization.
Unexpected loss of metadata, versions for a document management system(even without a warning of the loss) is unacceptable.

Friendly regards,

Nick